Question 9 · Track 3 · Deliver it to people
Design a news feed
Two strategies, and the famous person breaks both.
Deliver it to people. 4 clarifying questions to ask first, the answer in 4 moves, the follow-up that catches a memorised answer and 3 supporting topics to watch or read.
What it is really testing
Whether you can put the work at write time or read time on purpose, and whether you spot why neither is enough alone.
Ask these first
Before a single box goes on the board. The answers change the design, which is the point of asking out loud.
- How many followers does a typical account have — and the largest?
- How fresh must the feed be: seconds, or minutes?
- Chronological or ranked?
- How far back can someone scroll?
The answer, in 4 moves
In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.
- 1Fan-out on WRITE: push each post into every follower’s timeline. Fast reads, expensive writes.
- 2Fan-out on READ: pull from the people you follow at request time. Cheap writes, slow reads.
- 3Go hybrid — fan-out on write for normal accounts, on read for the huge ones.
- 4Keep the timeline in a cache; rank after retrieval, not during it.
The trap
The follow-up that separates a rehearsed answer from a real one.
The celebrity problem is the whole question. One account with ten million followers turns a single post into ten million writes, which is why no real system picks one strategy and stops.
Watch or read
The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.
Hot keys — one key, one node
Your cache dashboard says 10% average and everything is fine. One machine is at 96% and checkout is timing out. That is a hot key — one popular key, one node, and no amount of hardware. Here is how hash(key) picks the machine, why adding nodes takes the hot one from 96.00% to 95.50%, why consistent hashing with virtual nodes does nothing for it, and the three fixes that actually work — key splitting, an in-process cache, and request coalescing — with their real costs, every number executed.
Write-through vs write-back
Every caching tutorial teaches the read path. The bugs live on the write. Write-through, write-back and write-around with the real code for each, the measured cost of a durable write, and the data-loss window reproduced step by step.
View vs materialized view
You wrapped the slow query in a view and believed it made something faster. It did not. A view stores no data — it stores SQL text, so every SELECT re-runs the query from scratch. A materialized view stores the answer as a real table on disk you can index, which turns 40 seconds into milliseconds and charges you freshness. Here is exactly what each one is, why a materialized view is neither a cache nor an index, what REFRESH really costs (an exclusive lock, or CONCURRENTLY and a unique index), and the one question you must answer before you ship one.
Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.