Memcached

Best for

• ·High-throughput read-heavy workloads where maximum single-operation cache throughput is the priority and Redis data structures are not needed
• ·Session storage where loss of cached sessions on node failure is acceptable (or sessions are replicated at the application layer)
• ·Database query result caching where the application controls invalidation and cache-aside is the consistency model
• ·Page fragment caching for rendered HTML or API responses where the blob size fits within 1MB
• ·Environments where operational simplicity matters: Memcached has no persistence, no replication, and almost no configuration surface compared to Redis

Excels when

• ·All cached values are simple serialized blobs and Redis data structures (lists, sets, sorted sets, hashes) are not needed
• ·Cache is purely ephemeral: there is no data that must survive node restarts
• ·Multi-threaded throughput is the bottleneck and Redis's single-threaded event loop is a measured limitation
• ·Client-side sharding is acceptable and the client library used by all application services is consistent

Avoid when

• ·Workload requires data structures (sorted sets, lists, pub/sub, streams): use Redis
• ·Cache data must survive node restarts or process crashes: Memcached is purely volatile; use Redis with AOF/RDB persistence
• ·Replication is required for high availability of cached data: Memcached has no built-in replication; clients must implement their own dual-write logic
• ·Value sizes frequently exceed 1MB: the 1MB limit is a hard default requiring patch or alternative

Read scalability

Known failure modes

• ·Node failure causes a cold cache thundering herd: all requests for keys on the lost node simultaneously miss and hit the backing store: the backing store must handle the full uncached traffic volume
• ·Slab allocator fragmentation: Memcached allocates memory in fixed-size slabs; if value sizes change over the application lifetime, pre-allocated slabs for old sizes cannot be reclaimed without restarting the process
• ·Client-side consistent hash ring inconsistency: if different application instances use different library versions or configurations, the same key hashes to different nodes: silent dual-write and stale-read bugs
• ·Connection exhaustion: Memcached holds one OS thread per client connection by default; at very high client counts (>10,000 connections), thread scheduling overhead degrades throughput
• ·Silent eviction under memory pressure: when the LRU pool is full, items are silently evicted without notification; applications that assume cache presence will re-fetch from the backing store without knowing eviction occurred
• ·Value size limit: the default maximum value size is 1MB; storing larger objects (serialized blobs, large HTML fragments) silently fails with NOT_STORED without an error visible to the caller

Bottlenecks

• ·Node failure thundering herd: losing a node floods the backing store with the full uncached request rate for all keys on that node simultaneously
• ·Slab fragmentation: if value sizes are heterogeneous, memory allocated to large-value slabs cannot be reused for small-value slabs: memory efficiency degrades without a restart
• ·Client connection scaling: thread-per-connection model does not scale beyond a few thousand concurrent clients without significant memory overhead from thread stacks
• ·Single-machine memory cap: each node is bounded by its configured -m value; cluster capacity scales by adding nodes but each node is a hard memory boundary
• ·Consistent hash ring stability: any ring topology change (add/remove node) causes a cold miss wave proportional to the keys that rehash to a new node

Degradation patterns

• ·LRU eviction churn: when the working set exceeds pool capacity, high-value items are evicted to make room for less-valuable items: cache effectiveness degrades continuously without pool resizing
• ·Post-deployment cache miss wave: a new application deployment that changes serialization format invalidates all cached values that use the old format: backing store absorbs full traffic until the cache warms
• ·Network saturation: very high get throughput on large values can saturate the NIC on a Memcached node; monitor network bytes/s alongside operation count/s

Common topology roles