Serving a feed that feels fresh without rebuilding the whole world every time.
What makes a feed expensive: writing posts, reading posts, ranking posts, or delivering celebrity updates?
Before reading, decide whether you would build the feed on write, on read, or with a hybrid.
Feeds interleave storage, fan-out, ranking, caching, and freshness trade-offs.
To the user, a news feed looks simple: open app, see posts. Underneath, the expensive part is usually building the feed, not storing the post itself.
The system may need to know who the user follows, gather candidate posts, rank or sort them, attach media, and paginate the result. That is why a feed is really a read model, not just a table lookup.
The key design question is simple to say and important to answer: do I prepare the feed when the post is written, when the user reads it, or somewhere in between?
Interviewers use news feed because it forces candidates to talk about read-heavy behavior, fan-out on write versus fan-out on read, caching, ranking, hot users with huge follower counts, and media delivery.
The stronger answer names the real bottleneck: assembling the feed efficiently under different follower shapes.
A feed is just a query for posts from people you follow.
A feed is a delivery and freshness problem shaped by fan-out, ranking, celebrity accounts, and latency expectations.
Choose fan-out-on-write, fan-out-on-read, or hybrid based on relationship graph and freshness needs.
| Feed strategy | Good when | Weak when | Interview line |
|---|---|---|---|
| Fan-out on write | Most users have moderate follower counts and fast reads matter a lot. | Some accounts have massive fan-out and post frequently. | Fan-out on write makes feed reads simpler, but it can explode for celebrity-style accounts. |
| Fan-out on read | Writes should stay light and follower graphs are large or uneven. | Feed opens become expensive and repeated reads are slow. | Fan-out on read keeps writes cheap, but I pay more on every feed load. |
| Hybrid fan-out Default | Normal users benefit from precomputation, but very large accounts need special handling. | The added complexity is not justified at small scale. | A hybrid model lets me keep common reads fast without pushing every large fan-out cost into the write path. |
| Pure live ranking on read | Ranking needs maximum freshness and the scale is still modest. | Read latency and compute cost become too high. | I would only rank everything live if the scale is still small enough to afford it. |
| Cached feed fragments | Users reopen feeds frequently and repeated reads are common. | Feed contents are too dynamic or freshness requirements are extremely strict. | Caching feed fragments helps when many users refresh similar recent results repeatedly. |
This is the core trade-off in the chapter. The right answer is usually not ideological. It depends on follower shape, read latency goals, and how much write amplification you can afford.
This is the pressure test. If your answer still uses pure fan-out on write for everyone, the design breaks at the write path.
Do not jump straight from reading to a full answer. First see the shape, then complete part of it, then answer alone.
I would say: "For ordinary users I can precompute fan-out, but celebrity posts may need pull-time handling."
For a chronological feed, decide what gets precomputed and what is merged at read time.
Answer the practice prompt and name the feed-building strategy explicitly.
Before moving on, turn recognition into production. Close the model answer, answer from memory, then retry one small slice.
Say the chapter's core idea without looking. Then name one related idea from an earlier chapter.
Change one constraint in the practice prompt and answer again in half the time.
Use the rubric to pick one dimension below 3, then retry only that dimension.
Not storing posts.
You are moving cost, not eliminating it.
Follower shape matters as much as average traffic.