Overview
Memcached is a simple, high-performance, distributed in-memory cache. It stores opaque byte values under string keys with TTLs and evicts least recently used items when memory is full. It has no persistence, no replication, and no rich data types; clients spread keys across servers with consistent hashing.
That simplicity makes it very fast and easy to scale horizontally with multithreading on each node. Choose Memcached when you need a pure cache for large volumes of simple values; choose Redis when you need data structures, persistence, or replication.
Quick to write, quick to read, and when the board fills up the oldest notes are thrown away. If the board falls over, the notes are gone, and that is fine because the real information is in the files.
When to use it
- Pure caching of database query results, rendered fragments, or objects.
- Very large cache clusters where simplicity matters.
- Multithreaded performance on large machines.
- Data you can always rebuild from the source of truth.
Where it shows up in interviews
Recognize it when: cache in front of a huge database fleet.
- Design Facebook's caching layer
- Design a read-heavy social feed
Where it is used in real software
Operated one of the largest Memcached deployments, described in 'Scaling Memcache at Facebook', with leases and regional pools.
Have used Memcached to cache rendered pages and database results.
Offers managed Memcached alongside Redis.
Key terms
- Slab allocator
- Memory divided into size classes to limit fragmentation.
- LRU eviction
- Remove least recently used items when full.
- Client-side sharding
- Clients hash keys to choose a server.
- CAS
- Check-and-set with a version token for optimistic updates.
How it works, step by step
- 1Client hashes the key
Consistent hashing picks one server.
- 2get(key)
Returns the value or a miss.
- 3On miss, load from the DB
Then set(key, value, ttl).
- 4On write, delete the key
Invalidate rather than update.
- 5Server evicts under memory pressure
LRU within slab classes.
Memcached vs Redis
Both are in-memory caches
| Aspect | Memcached | Redis |
|---|---|---|
| Data types | Strings (bytes) | Strings, hashes, lists, sets, sorted sets, streams |
| Persistence | None | RDB / AOF |
| Replication | None built in | Primary-replica, Sentinel, Cluster |
| Threads | Multithreaded | Single-threaded commands (threaded I/O) |
| Max value size | 1 MB default | 512 MB |
NOWAspect: Data types | Memcached: Strings (bytes) | Redis: Strings, hashes, lists, sets, sorted sets, streams
For a plain cache either works; Redis is more common today because the extra features are often useful.
Implementation
import Memcached from "memcached"; // Client hashes keys across serversconst cache = new Memcached(["cache-1:11211", "cache-2:11211", "cache-3:11211"]); function getUser(id: string): Promise<User> { return new Promise((resolve, reject) => { cache.get(`user:${id}`, async (err, data) => { if (err) return reject(err); if (data) return resolve(JSON.parse(data)); const user = await db.users.findById(id); cache.set(`user:${id}`, JSON.stringify(user), 300, () => resolve(user)); // 5 min TTL }); });}Complexity and performance
Sub-millisecond.
With consistent hashing.
Trade-offs
Memcached is easy to operate but lacks data structures, persistence, and replication.
Lost nodes mean misses until the cache warms up; protect the database with request coalescing.
Variants and related techniques
Facebook's proxy for routing, replication, and failover across Memcached pools.
Common mistakes
- Storing data that cannot be rebuilt.
Fix: Memcached is not durable.
- Thundering herd on popular key expiry.
Fix: Use leases or request coalescing and TTL jitter.
Interview questions
When would you pick Memcached over Redis?
For a large, simple, multithreaded cache of opaque values where persistence and data structures are unnecessary, and simplicity at scale matters.
What happens when a Memcached node dies?
Its keys become misses and are reloaded from the database; with consistent hashing only that node's share of keys moves.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Compare Memcached and Redis for a session store | Easy | Durability needs. |
| Design a caching layer for 1M reads/s | Hard | Pools, hashing, herd protection. |