A look-aside cache at Facebook's scale
Design a Distributed Cache (Memcache), from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
A social network renders every page from many small pieces of data: profiles, friend lists, posts, counts, permissions. A popular page fetches hundreds of distinct items; Facebook reported an average of 521 for its most popular pages. MySQL holds the truth, but it cannot serve this read load, and it is provisioned only for the traffic that misses the cache.
So the web servers use memcached as a demand-filled, look-aside cache: read the cache; on a miss, query the database and put the result in the cache. Reads exceed writes by orders of magnitude, and a little staleness is acceptable, as long as people see their own changes and nothing stays stale for long.
Facebook described how this grew from one cluster to many clusters and regions in "Scaling Memcache at Facebook" (NSDI 2013).
What the interviewer would tell you if you asked
- Billions of cache reads a second across the fleet; writes are a tiny fraction.
- A page needs hundreds of keys, fetched in parallel batches.
- One master region holds the MySQL primaries; other regions have read replicas.
- Cached values are small and derived from the database.
- Any cached key can be evicted at any time.
- Brief staleness is acceptable for most data.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.