Memcached
Memcached is a high-performance, in-memory key-value cache. It does one thing: store opaque values under string keys, in RAM, for a limited time, and return them extremely quickly. There are no data structures, no persistence, no replication, and no query language — and that simplicity is the point. A Memcached node is multithreaded, predictable in memory use, and easy to operate, and a pool of nodes scales almost linearly because the clients decide which node holds each key.
Memcached powered the scaling of many of the largest early web applications by absorbing database reads, and it remains a strong choice for a pure cache. When you need more than a cache — counters with persistence, sorted sets, streams, pub/sub — Redis is usually the better fit.
TL;DR
- Stores opaque byte values under keys of up to 250 bytes; values up to 1 MB by default.
- Everything is in memory and may disappear at any time — on restart, eviction, or expiry.
- Memory is managed in slab classes with LRU eviction when full.
- Clients spread keys across nodes with consistent hashing; nodes do not talk to each other.
- Typical use is cache-aside: read from cache, fall back to the database, then populate the cache.
- Never expose Memcached to the internet; keep UDP disabled and use private networking with SASL or TLS where needed.
Quick Example
Cache-aside for user profiles in Python, spread over two nodes with pymemcache:
Running a node:
Core Concepts
Commands
The newer meta protocol (mg, ms, md, ma) combines these with flags for features such as returning remaining TTL, serving stale values while one client recaches, and avoiding stampedes. The older binary protocol is deprecated.
Memory: Slabs and LRU
Memcached divides memory into slab classes, each holding items of a size range. Items go into the smallest class that fits. When memory is full, the least recently used items in that class are evicted. A segmented LRU with a background crawler also reclaims expired items early. Modern versions rebalance memory between classes automatically, but workloads that change item sizes drastically can still waste memory.
Distribution
Nodes are independent. The client library hashes each key to choose a node — with consistent hashing, adding or removing one node remaps only a fraction of keys rather than all of them. Large deployments often add a proxy layer, such as mcrouter or Memcached's built-in proxy, for routing, replication of hot keys, and failover.
Expiry
Each item has an expiry: seconds from now (up to 30 days) or a Unix timestamp. Items can also be evicted before expiry when memory runs out. Applications must always treat a cache miss as normal.
Patterns
Cache-Aside
The application reads from the cache, falls back to the source on a miss, and writes the result back with a TTL. On updates, it deletes the key rather than writing the new value, avoiding races where a stale write lands after a fresh one. See Redis Caching Patterns for the same patterns with Redis.
Stampede Protection
When a popular key expires, many requests miss at once and all hit the database. Options:
- Lease or lock: the first client to miss uses
addon a lock key and recomputes; others wait briefly or serve stale data. - Meta protocol stale-while-revalidate: one client is told to recache while others receive the stale value.
- Jittered TTLs: avoid many keys expiring at the same moment.
- Early refresh: refresh popular keys probabilistically before they expire.
Namespacing and Invalidation
Prefix keys with a version (user:v2:) or a namespace counter so that changing a serialization format or invalidating a whole group means changing the prefix, not deleting millions of keys.
Memcached or Redis
Managed options for both exist, such as Amazon ElastiCache.
Best Practices
Treat the Cache as Disposable
Every code path must work with an empty cache. Test cold starts and node failures, and make sure a cache outage degrades latency rather than availability.
Set Short Client Timeouts
A slow cache is worse than no cache. Use timeouts measured in milliseconds and treat errors as misses.
Monitor Hit Rate, Evictions, and Memory
Track hit ratio, evictions, connections, and per-slab statistics (stats, stats slabs). Rising evictions with a falling hit rate means the cache is too small or keys are too large.
Secure the Network
Bind to private interfaces, keep UDP disabled, restrict access with security groups or firewalls, and enable SASL authentication or TLS where untrusted clients share the network.
Common Mistakes
Exposing Memcached Publicly
Updating the Cache Instead of Deleting
Unbounded Values
FAQ
What is Memcached used for?
Caching the results of expensive operations — database queries, API calls, rendered fragments, computed objects — in memory across a pool of servers, to reduce latency and load on the systems behind it.
Does Memcached persist data?
No. Data lives only in memory and is lost on restart. Items can also be evicted at any time when memory is full. Applications must always be able to rebuild data from the source.
How does Memcached scale across servers?
Clients hash each key to a server, usually with consistent hashing, so each server holds part of the data. Servers are unaware of each other, which keeps them simple and lets the pool grow almost linearly.
Is Memcached faster than Redis?
For simple get and set operations both are extremely fast, and Memcached's multithreading can give higher throughput per node for simple workloads. The more important difference is features: Redis offers data structures, persistence, and replication.
What is the maximum item size?
1 MB by default, configurable with the -I option. Very large items are usually a sign that data should be split into smaller cached units.
Related Topics
- Caching — Caching strategies across the stack
- Redis — In-memory data store with richer features
- Caching Layers — Where caches sit in an architecture
- Redis Caching Patterns — Cache-aside, write-through, and stampede handling
- Amazon ElastiCache — Managed Memcached and Redis
- Performance & Optimization — Where caching fits in performance work