intermediate 2 min answer

Precompute every user's timeline at write time, or assemble it at read time? Explain why the answer for a social feed is neither.

case-studytwitterfan-outpower-lawcaching
Show the full answer Hide the answer

Why each pure strategy fails

Fan-out on read. Store each post once; on timeline load, query the posts of everyone the user follows and merge. Writes are trivial. Reads become a scatter-gather across hundreds of accounts — executed far more often than posts occur, since reads outnumber writes by orders of magnitude. The cost lands in the wrong place.

Fan-out on write. On posting, write the post into every follower's precomputed timeline. Reads become a single sequential fetch, extremely fast. But a post from an account with tens of millions of followers becomes tens of millions of writes — one user action landing like a self-inflicted denial of service.

The hybrid

Fan-out on write for ordinary accounts; exclude very-high-follower accounts and merge their posts at read time.

Most timelines are precomputed and instant. The few accounts that would cause write storms are handled by a cheap read-time merge — cheap precisely because there are very few of them per timeline.

Why this is a general pattern, not a Twitter trick

Power-law distributions defeat uniform strategies. Almost every social, commercial and content system has a small number of enormously popular entities and a very long tail. A design tuned for the median entity fails at the head; one tuned for the head is wasteful for everything else.

The reusable move is to treat the head as an explicit special case:

  • Multi-tenant sharding — the largest tenants get dedicated shards.
  • Caching — the hottest keys get request coalescing or an in-process cache.
  • Rate limiting — the largest customers get bespoke limits.
  • Inventory — the most contended SKUs get a different concurrency strategy.

The design-time question

Look at the distribution before choosing an algorithm. "How does this behave for the 99.9th percentile entity?" is a question to ask during design, and the answer is frequently that you need two strategies and a threshold — which is less elegant and considerably more correct.

What a strong answer adds

Noting the operational consequences of the hybrid: the threshold is a tunable that needs monitoring, accounts cross it in both directions (so there must be a migration path for a timeline), and the two paths must produce consistently ordered results or users see posts appear out of sequence. Hybrids are correct and they are not free.