software-engineer-blog logoSoftware Engineer Blog

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.

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.

  1. 1Fan-out on WRITE: push each post into every follower’s timeline. Fast reads, expensive writes.
  2. 2Fan-out on READ: pull from the people you follow at request time. Cheap writes, slow reads.
  3. 3Go hybrid — fan-out on write for normal accounts, on read for the huge ones.
  4. 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.

ReelRead

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.

ReelRead

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.

ReelRead

Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.