Memcached primer
Drop-in in-memory object cache that slashes database load. Learn the mental model, wire it into your stack, and avoid the footguns that bite teams at 3 AM.
The mental model
Memcached is a giant hash table in RAM. You push key-value pairs in, it serves them back at sub-millisecond latency. No query language, no replication, no persistence. When RAM fills up, it evicts the least-recently-used keys. That simplicity is the superpower.
When to reach for it
- Database query results that are expensive and read-heavy
- Session storage where sticky routing already exists
- Rate-limit counters that tolerate eviction
- Rendered HTML fragments or API response blobs
The cache-aside pattern
Application checks Memcached first. On miss, it queries the database, writes the result into Memcached with a TTL, and returns it. On write-through or invalidation, the app deletes the corresponding key so the next read repopulates it. Never let the cache drift from the source of truth.
TTL discipline
Every key gets an expiration. Short TTLs (30–300s) keep memory pressure low and stale data rare. Longer TTLs are acceptable for immutable reference data. Avoid infinite TTLs — they turn your cache into a ghost database that nobody remembers to purge.
Common footguns
- Thundering herd: dozens of workers miss the same key simultaneously and hammer the database. Fix with probabilistic early recomputation or a lock on cache miss.
- Key collisions: prefix keys with namespace and version (e.g.
v2:user:421:profile). - Hot keys: a single key saturates one node. Shard it across multiple keys or replicate it locally.
- Serialization drift: changing the object schema without bumping the key prefix poisons the cache with unreadable blobs.
Quick start
Spin up Memcached via Docker, install a client library for your language, and wrap your most expensive read query in the cache-aside pattern. Measure hit rate and p99 latency before and after. A 90% hit rate with sub-millisecond reads is the baseline target.