SYSTEM DESIGN · QUESTION 30
How would you design a scalable news feed?
On this page
I would clarify feed freshness, ranking, follower counts, and pagination, then separate post creation from feed reads. A common design stores posts durably and builds a user’s feed from followed accounts, using fan-out on write for ordinary accounts and read-time merging for very large ones. Caching and cursor pagination help reads, while ranking and privacy checks shape what each user sees.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A feed collects posts from accounts a person follows and chooses which ones to show. The challenge is that users may follow many accounts, some accounts may have enormous audiences, and the feed must stay reasonably fresh. One design prepares each user’s feed when a post is created; another gathers posts when the user opens the app. Many systems combine both approaches.
A USEFUL COMPARISON
Picture it this way
A newspaper can be assembled in advance for each subscriber, or a reader can visit several sections and pick stories at reading time. Preparing personalized copies makes reading quick but creates work when a popular source publishes. Gathering everything on demand avoids precomputing every copy but makes opening the feed slower.
FOLLOW THE JOURNEY
Balance feed precomputation with read-time assembly
Compare write-time fan-out and read-time aggregation for feed delivery.
Hybrid fan-out avoids writing a popular author’s post into every follower feed while keeping common reads fast. The right threshold depends on workload and product behavior.
A post is stored and distributed to follower feed entries for ordinary authors, while high-follower authors are merged at read time before ranking and returning a paginated feed.
How to read this visual
Hybrid fan-out avoids writing a popular author’s post into every follower feed while keeping common reads fast. The right threshold depends on workload and product behavior.
UNDER THE HOOD
How it works, step by step
Clarify product requirements
Ask about ranking, freshness, privacy, pagination, edits, and expected read/write patterns.
Why it matters: These choices determine whether feed entries are materialized or assembled on demand.
Store posts and relationships
Persist posts, author state, follower relationships, and visibility rules.
Why it matters: Feed generation needs durable source data and permission context.
Distribute post references
Fan out to follower feeds for typical accounts and defer very large audiences to read time.
Why it matters: Hybrid fan-out balances write amplification and read latency.
Rank, filter, and paginate
Merge candidates, enforce privacy, rank them, and return a cursor.
Why it matters: A feed is personalized and changes while users are paging through it.
OUTSIDE THE TEXTBOOK
A practical example
When an ordinary account posts, a background worker writes a reference into followers’ feed timelines. For a celebrity account with a very large audience, the system stores the post once and merges it into a follower’s feed when they read. The feed service then checks visibility, ranks candidates, and uses a cursor so later pages do not rely on a fragile numeric offset.
GO A LITTLE DEEPER
Technical details that matter
- Fan-out on write makes reads fast but increases writes and can make publishing to large audiences expensive.
- Fan-out on read reduces write amplification but increases read work and latency.
- Cursor pagination based on stable ordering keys is often more robust than offsets when new posts arrive between page requests.
- Caching personalized feeds must respect privacy changes, deletions, blocks, and ranking updates.
MAKE A GOOD CHOICE
When is this useful?
- Social timelines assembled from followed authors or topics.
- Activity streams where read latency and freshness both matter.
- System-design discussions about fan-out, ranking, caching, and pagination.
A chronological query over indexed posts can be sufficient for a small product. Avoid materializing personalized feeds until measurements show read-time assembly is a bottleneck.
WATCH OUT FOR
Common misunderstandings
- Choosing fan-out on write for every account without considering very large audiences.
- Using offset pagination while new items shift results between page requests.
- Treating cached feed entries as permission to show content after access has changed.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Hybrid fan-out adds multiple data paths and consistency work.
- A user’s feed may be briefly stale while background fan-out catches up.
- Ranking can be expensive and difficult to evaluate fairly across user segments.
WHAT TO REMEMBER
Key takeaways
- 1Separate durable post storage from personalized feed delivery.
- 2Choose write-time, read-time, or hybrid fan-out based on audience size and workload.
- 3Enforce privacy during feed assembly and caching.
- 4Use stable cursors and define freshness expectations.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
When would you use fan-out on write?
It works well when authors have manageable follower counts and fast feed reads are important. Very large audiences can make write amplification excessive.
How do you handle a very popular author?
Store the post once and merge it at read time, or use a hybrid threshold, while monitoring the added read cost.
How would you paginate a changing feed?
Use a cursor based on stable ordering fields, such as a timestamp plus unique ID, and define how new or removed posts affect subsequent pages.
SAY IT OUT LOUD
How to explain this in an interview
“I would clarify freshness, ranking, privacy, and expected follower distributions. Posts are stored durably, then distributed using a hybrid strategy: fan out to followers for typical accounts, but merge very large accounts at read time. The feed service ranks and filters candidates and returns cursor-based pages. This balances read latency against write amplification, while privacy and cache invalidation remain essential.”
Connect this question to the roadmap topic it supports.