Case studies are where isolated system design topics finally become one architecture conversation.
A social feed is useful because it combines heavy reads, timeline freshness, fan-out decisions, caching, ranking, and high traffic variance.
There is no single perfect social feed design. The quality of the answer comes from how clearly you explain the tradeoffs.
This lesson is about stitching earlier concepts together into a believable reasoning flow.
A social feed forces you to think about many pressures at once: the number of reads versus writes, the cost of producing timelines, the freshness users expect, and how recommendations or ranking might complicate the feed generation path.
It is also a strong interview case because it rewards structured thinking rather than rote memorization.
A strong answer begins by clarifying whether this is a simple chronological feed, a ranked feed, a follower model, a celebrity-heavy workload, or a smaller community system. Those distinctions change fan-out strategy and read amplification dramatically.
From there, a good design answer explains how posts are written, how feed entries are generated, where caching helps, what storage holds source data versus feed views, and what tradeoffs the design accepts around freshness and cost.
Clarify the first version: users publish posts, follow accounts, open a home feed, and delete their own posts. Define whether the feed is chronological or ranked, how fresh it should be, whether private accounts exist, and the expected read-to-write ratio. Exclude comments, stories, and recommendations until the core flow is coherent.
Store users, follow relationships, and post metadata in authoritative databases, while media lives in object storage behind a CDN. A feed service retrieves candidate post IDs, applies visibility rules, ranks or orders them, hydrates post details, and returns cursor-paginated results. Cache public immutable media separately from personalized feed results.
For a small system, fan-out on read can query recent posts from followed accounts. As scale grows, precompute feed entries for typical users when a post is published. Celebrity accounts may have millions of followers, so use a hybrid strategy that merges their posts at read time rather than writing millions of feed rows synchronously.
Follow-up questions often target edge cases: celebrity fan-out, cold-start recommendation quality, cache invalidation, ordering correctness, abuse handling, or regional scaling. These are opportunities to show tradeoff thinking, not reasons to panic.
The best response style is to acknowledge the new pressure, explain what part of the design it stresses, and then adjust the architecture or operational strategy with clear reasoning.
Model celebrity and ordinary-user traffic, then combine fan-out-on-write for typical accounts with fan-out-on-read for very high-fan-out publishers.
Pure write fan-out makes celebrity posts expensive, while pure read fan-out raises latency for every feed view. Ranking and deletion also complicate cached feed entries.
Verification must use evidence that matches the concept. Estimate fan-out work, storage, read latency, and freshness; trace publish, follow, unfollow, delete, ranking, cache miss, and regional failure paths. Repeat the check after deliberately introducing the failure, then after the fix. The contrast between those runs is the part that turns a definition into practical understanding.
Ranking combines freshness, relationship strength, predicted interest, and product policy. Candidate generation and ranking should be separable so models can change without rewriting storage. Log impression and interaction events carefully, handle delayed signals, and prevent feedback loops from overwhelming diversity.
Event-driven fan-out uses durable post events, partitioned workers, idempotent feed writes, retry policy, and dead-letter handling. Deletes and privacy changes must remove or filter old feed entries. Reconciliation jobs compare authoritative posts and relationships with derived feeds when consumers fall behind or bugs create inconsistency.
Protect the system from spam, scraping, abusive follows, and malicious media. Apply rate limits, content checks, privacy enforcement, and auditability. Monitor publish latency, fan-out lag, feed read latency, cache hit rate, ranking failures, stale or unauthorized impressions, and hot partitions. Define degraded behavior when ranking or fan-out services are unavailable.
A feed page needs a stable continuation contract while new posts arrive and ranking changes. Offset pagination can skip or repeat entries when earlier rows are inserted. An opaque cursor can carry a position such as ranking version, score boundary, timestamp, and post ID tie-breaker. Keep cursor contents signed or server-owned, set an expiry policy, and define what happens when the ranking model or viewer permissions change between pages.
Deduplicate post IDs at merge boundaries because fan-out, retries, cached pages, and live inserts can overlap. Do not promise a total global order unless the product requires and can afford one. A practical contract may preserve monotonic navigation within a short session while allowing newly ranked content on refresh. State that behavior so clients do not infer consistency the backend never guarantees.
Fan-out on write is efficient for ordinary authors with bounded follower counts but expensive for accounts with millions of followers. Keep celebrity posts in an author timeline and merge them during reads, while precomputing ordinary followees into inboxes. Cold or inactive users may not justify continuous inbox writes; rebuild or lazily fill their feed when they return.
Block, unfollow, account privacy, and post deletion must affect cached and precomputed feeds, not only the source row. Apply an authorization filter on reads as a safety boundary, publish invalidation events, and reconcile derived entries. Measure time to remove unauthorized impressions and define a stricter synchronous path for changes whose exposure risk cannot tolerate normal propagation lag.
This outline is a much better starting point than jumping straight into random components.
Clarify feed semantics -> estimate read/write ratio -> define write path for posts -> define feed generation strategy -> choose cache and storage approach -> discuss celebrity edge cases and fallback behavior -> explain observability and failure handlingPublish post -> durable post store
Normal author -> enqueue fan-out jobs -> follower feed stores
Celebrity -> store post reference only
Read feed -> merge precomputed entries + celebrity posts
Rank -> hydrate -> filter deleted/private contentTypical accounts fan out on write while high-fan-out accounts merge on read.
Publish post -> store post metadata and media reference
Commit outbox event -> message stream
Normal author -> workers append post ID to follower feed stores
Celebrity author -> skip broad fan-out and mark as read-time source
Read feed -> load precomputed IDs
Merge recent celebrity posts
Apply privacy and deletion filter
Rank, hydrate, and return cursorEstimate the paths that dominate architecture decisions.
10 million daily active users
8 feed opens per user per day
Average read rate: about 926 requests/second
Peak multiplier 5: about 4,630 requests/second
500,000 posts per day
Average 300 followers, highly skewed distribution
Normal fan-out writes: roughly 150 million feed entries/day
Celebrity posts handled by read-time mergeNo. The best design depends on feed semantics, scale, ranking complexity, and what tradeoffs the product is willing to accept.
Because they force you to combine many design ideas at once and explain how those ideas interact under real constraints.
Explore 500+ free tutorials across 20+ languages and frameworks.