Design a Social Media Feed
Practice a social-media-feed design with fanout choices, ranking boundaries, celebrity skew, freshness, cache invalidation, and feed recovery.
What you'll learn
Run the architecture drill
- How fanout-on-write and fanout-on-read serve different follower distributions.
- Why ranking, cache invalidation, and privacy changes need explicit boundaries.
- How to reason about celebrity traffic and feed freshness in an interview.
A social feed is a personalized read model built from a changing social graph and a high-volume stream of content. The interesting tradeoff is not simply storing posts. It is deciding when to fan out content, where to rank it, how to handle celebrity skew, and how to make freshness and deletion behavior acceptable.
Start with the architecture drill, then follow the request path through scale, failure, and a defensible interview answer.
Make your assumptions and decision path easy to inspect.
ATOFF architecture reasoning canvas
Design a Social Media Feed: the architecture drill
Short answer
A social feed is a personalized read model whose central decision is where and when to fan out content while preserving freshness, privacy, and recovery.
10× evolution
Blend fanout modes and rebuild projections from durable posts and graph state.
01 Decision checkpoint
Design brief
Set the contract for recency, ranking, privacy changes, deletion, and pagination before deciding whether feeds are pushed or assembled on read.
02 Decision checkpoint
First request path
Fan out ordinary authors to follower inboxes when writes are manageable, but read-assemble celebrity content to avoid explosive write amplification.
03 Decision checkpoint
Failure drill
Keep source posts and graph state durable so delayed fanout, ranking changes, deleted content, and cache loss can rebuild a feed deterministically.
Say it in the interview
I would separate the source-of-truth post graph from the feed projection, then choose fanout strategy by follower skew and freshness target.
- 1
Creator
publish post: Canonical post store
- 2
Canonical post store
ordinary audience: Push fanout for normal accounts · celebrity candidate: Pull candidates for high-fanout accounts
- 3
Social graph + policy
followers + visibility: Push fanout for normal accounts
- 4
Push fanout for normal accounts
inbox candidates: Viewer ranker + freshness rules
- 5
Pull candidates for high-fanout accounts
pull candidates: Viewer ranker + freshness rules
- 6
Viewer ranker + freshness rules
ranked page: Feed cache
- 7
Feed cache
serve feed: Viewer
- 8
Viewer
feed request: Viewer ranker + freshness rules
- Creator flows to Canonical post store via publish post.
- Canonical post store flows to Push fanout for normal accounts via ordinary audience.
- Social graph + policy flows to Push fanout for normal accounts via followers + visibility.
- Canonical post store flows to Pull candidates for high-fanout accounts via celebrity candidate.
- Viewer flows to Viewer ranker + freshness rules via feed request.
- Push fanout for normal accounts flows to Viewer ranker + freshness rules via inbox candidates.
- Pull candidates for high-fanout accounts flows to Viewer ranker + freshness rules via pull candidates.
- Viewer ranker + freshness rules flows to Feed cache via ranked page.
- Feed cache flows to Viewer via serve feed.
Walk the design under pressure
Clarify the feed promise and graph shape
Ask whether the feed is chronological or ranked, follows are directional or mutual, privacy changes are immediate, posts can be edited or deleted, and content is global or regional. The social graph and audience distribution drive the data model more than a generic "posts per second" estimate.
Separate the canonical post record from a viewer's feed representation. A feed entry is a candidate or projection, not the only source of truth for the post's current visibility or policy state.
Choose fanout from follower distribution, not dogma
Fanout-on-write pushes a post into follower feed inboxes early, making reads fast for ordinary accounts with a manageable audience. Fanout-on-read gathers candidates when a viewer requests their feed, avoiding huge writes for celebrity accounts but making reads more expensive.
Most realistic designs are hybrid. Use precomputed fanout for normal follows, pull celebrity or high-volume sources at read time, and keep the decision visible in the architecture so the team can evolve the threshold as behavior changes.
Ranking and freshness create a consistency contract
A ranking service can combine recent posts, relationship strength, quality signals, and product rules, but it should not make a feed irreproducible. Store enough candidate and version information to debug why an item appeared. Cache feed pages briefly, then define how new content, blocks, deletes, and privacy changes invalidate or filter them.
A user may accept a slightly delayed noncritical post, but they should not see content they no longer have permission to access. That distinction tells you which policy checks must happen on the read path even when most work is precomputed.
Staff-level insight: protect against skew and make ranking accountable
At staff level, model celebrity skew, hot partitions, abuse-driven fanout, ranking feature cost, and the operational impact of a graph migration. Measure feed freshness, candidate generation lag, invalidation errors, cache hit rate, and policy-filter removals—not just request volume.
In an interview, explain the architecture evolution from chronological feed to hybrid fanout and ranking. Strong answers acknowledge that relevance is a product decision with operational and fairness consequences, not just a machine-learning endpoint.
Keep this with you
Key takeaways
- A feed is a personalized projection over canonical posts and a social graph.
- Fanout-on-write and fanout-on-read should be selected per audience shape, often in a hybrid design.
- Freshness, ranking, privacy, and deletion require an explicit read-time consistency contract.
Practice aloud
Interview questions to explore
- 1.How do you prevent a celebrity post from creating unbounded fanout work?
- 2.What must be checked at read time after a privacy or block change?
- 3.How do you explain why a given item appeared in a user's feed?
Common follow-ups
Frequently asked questions
Is fanout-on-write always faster?
It makes many reads faster by precomputing feed entries, but it can be prohibitively expensive for large audiences and requires invalidation when posts or relationships change.
Can a feed be both ranked and chronological?
Yes. Product rules can combine chronological candidates with ranking or offer distinct modes. The architecture must make the chosen ordering and freshness behavior understandable.
Already an Elite member? Open the complete walkthrough.
Need the broader preparation context? Go back to Interview Preparation for behavioral readiness, question practice, and the larger AceTheOffer preparation framework.