Meta (Facebook): caching in front of a database
Memcached as a look-aside cache at very large scale, where the hard part is keeping it correct rather than fast.
The idea
A look-aside cache is easy to describe: read from the cache, fall back to the database on a miss, and fill the cache with what you found. Facebook's memcache paper is the best account of what goes wrong when you lean on that pattern hard.
Most of the paper is about correctness and load, not speed. Writers delete keys instead of updating them, because deletes cannot land in the wrong order. Leases stop a slow reader from putting a stale value back after a delete, and stop thousands of readers from querying the database for the same missing key at once. Deletes are driven from the database's commit log, so a crash cannot lose them. A small pool of idle servers takes over a failed server's traffic, so its keys do not fall through to the database.
It is a long paper, but each mechanism is introduced by the problem that forced it, so it reads well one section at a time.
Read the originals
Written by the engineers who built it.
- Scaling Memcache at Facebook
Rajesh Nishtala and others · Paper, Apr 2013
The reference on running a look-aside cache hard: leases, invalidation from the commit log, failover without hammering the database, and consistency across regions.
Practise it
Make the decisions yourself, then compare.