Fan-out on write and fan-out on read
When one write must reach many readers, do the work when it is written (precompute every reader's view) or when it is read (assemble it on demand). Most real feeds do both.
Performance & scale
Learn it
A post from someone with ten million followers must appear in ten million home feeds. A feed shows posts from hundreds of accounts. Somebody does the multiplication between "one author" and "many readers"; the question is when.
- Fan-out on write (push): when an item is written, insert a reference into every reader's precomputed list. Reads are one lookup; writes cost O(followers).
- Fan-out on read (pull): store each item once. At read time, fetch recent items from everyone the reader follows and merge. Writes are O(1); reads cost O(following).
Check
Feeds are read about 50 times for every post. Which side should usually pay?Work it out
One author has 10 million followers. With pure fan-out on write, how many timeline inserts does one post cost?The standard answer is hybrid: push for ordinary authors; for the few with huge audiences, skip fan-out and merge their recent items in at read time. Two refinements:
- Don't fan out to people who aren't reading. Precompute only for recently active users; rebuild the rest when they return.
- Store references, not copies, so edits and deletions don't need another fan-out.
Quick reference
The same ideas, condensed for revision.
How it goes wrong
- Celebrity write amplification
- One post becomes millions of inserts; delivery lags for minutes and queues back up behind it.
- Wasted work on inactive readers
- Most precomputed entries are never read.
- Deletes that don't propagate
- Copies of content (not references) fanned out to timelines keep showing deleted posts.
Instead, consider
- Pure fan-out on read
- Writes are frequent, reads are rare, or each reader follows few sources (search is the extreme case).
- Pure fan-out on write
- Audiences are bounded (group chats, small teams) so no single write is enormous.
In practice
- Redis lists per user
- Capped lists of item IDs, the classic home-timeline store.
- Wide-column stores
- One partition per reader, clustered by time.
- Merge at read time
- Fetch high-audience authors' recent items and merge by score or time.
It assumes
- Reads of the combined view vastly outnumber writes.
- A short delay between writing and appearing in every reader's view is acceptable.
- Most authors have modest audiences; a few have enormous ones.
Explain it in your own words
Where you practise it
- A home timeline at 300,000 reads a second
What the numbers say · When does the multiplication happen? · Trace a post to a follower's screen · Thirty million followers · Timelines nobody reads · The post that wouldn't die · Write the merged read · Top posts first · Defend the hybrid
- Live queries: screens that update in real time
Further reading
Engineers describing it in systems they run.
- Timelines at Scale
Twitter (X) · Raffi Krikorian · Talk, Apr 2013
A talk on how home timelines were served: fan-out on write into a cache, what that costs for very large accounts, and why timelines are treated as rebuildable.
Related concepts
- Caching
Keeping a copy of data closer to where it is used, trading freshness and complexity for speed and reduced load on the source.
- Partitioning
Splitting data or work by key so each part is handled independently: scaling out, and giving each key a single owner.
- Asynchronous processing
Accepting a request, recording the work durably, and doing it later in another process, so the work can outlive the request.
- Publish/subscribe
Decoupling senders from receivers by topic: a publisher sends once and every current subscriber receives a copy.