Design a news feed: the social media feed design interview walkthrough

Design a news feed: the social media feed design interview walkthrough

The request to design a news feed sounds like one line — show a user the recent posts from the people they follow — and that one line hides the whole interview. Doing it for a few hundred users is a database query; doing it for billions of users, where some accounts have 100M+ followers and every feed has to load in under a second, is a fanout and read-scale problem with one brutal edge case. This is one of the most common news feed system design prompts because it forces the tradeoff every large read-heavy system eventually hits: do you pay the cost up front when a post is written, or every time a feed is read?

The round turns on two decisions. First, the shape of the write path: a social media feed is read far more than it is written, so you lean toward precomputing feeds — but precomputing means fanning every post out to every follower, and that is where the design can fall apart. Second, what happens when a single account has tens of millions of followers, which is where the celebrity problem and the hybrid answer come in. This walkthrough follows the path a strong candidate draws in a system design interview — requirements, estimate, API and data model, high-level design, then the deep dives — and at each step it names the follow-up the interviewer uses to tell a memorised answer from an engineer who understands the tradeoff.

How the news feed round is actually run

A news feed round runs about 60 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem opens onto deep water fast: the moment you say "I'll precompute each user's feed," the question becomes what about the account with a hundred million followers, and every answer after that (the celebrity problem, the hybrid, the cache, ranking) compounds. Get the fanout spine clean and you have shown the whole loop in one problem.

The interviewer rarely lets "precompute every feed" stand. "A user with a hundred million followers posts — walk me through exactly what happens when they hit publish." That question — the write storm a naive fanout-on-write creates — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a clock, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

1. Clarify requirements — functional and non-functional, and what you are explicitly not building.
2. Estimate — users, posts, reads and the follower distribution, to justify every later choice.
3. High-level design — the boxes and arrows: client, feed API, feed service, fanout service, stores.
4. Deep dive — the two or three decisions that actually decide this system.
5. Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reach a fanout design and then recognise the celebrity problem it creates), communication (did you say why push beats pull for most users in a sentence), technical execution (precomputed feed cache, hybrid fanout, cursor pagination, ranking at read), and time management (did you spend your 60 minutes on fanout and the celebrity case, not on the post schema). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a news feed must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Publish a post; generate a user's feed of posts from the accounts they follow; rank the feed; paginate it with infinite scroll.
Functional (optional)	Likes and comments, media (images, video), ads — call these out, then scope most of them for later.
Non-functional	Very low feed-read latency (feed loads in under a second); read-heavy (far more feed reads than posts); highly available; eventual consistency is acceptable — a new post can appear in a follower's feed a little late.

The sentence that earns points: "The feed is read far more than it is written, and eventual consistency is fine, so the whole design is about moving work off the read path — which means precomputing feeds, and then handling the accounts where precomputing explodes." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the hard axis is the follower distribution, not raw volume.

Quantity	Assumption	Result
Daily active users	1B	—
Posts	~2/user/day for a fraction of users	~100M+ new posts/day
Feed reads	many refreshes/user/day	read:write heavily skewed toward reads
Followers per account	most have a few hundred	a normal post fans out to hundreds
Followers per mega-account	some have 10M–100M+	a single post fans out to tens of millions

The conclusion to say out loud: the cost is not the average post — it is the shape of the follower graph. Most accounts are cheap to fan out, so for them you precompute. A handful of mega-accounts are catastrophic to fan out on write — one post would mean 100M writes — so they must be handled differently. The whole design lives or dies on the cost of fanning a post out to followers versus the cost of assembling a feed at read time, dominated by that handful of huge accounts. You have now pointed the interview at the real deep dive — fanout — before anyone asked.

Step 3 — API and data model

The API is small. A write path to publish a post, and a read path to fetch a page of the feed:

Endpoint	Operation
POST /post	Publish a post — createPost(user_id, body, media?) returns a post_id.
GET /feed	Fetch a page of the feed — getFeed(user_id, cursor, limit) returns ranked post ids + a next cursor.
POST /follow / DELETE /follow	Follow or unfollow an account — mutates the follow graph.

The data model splits across a few stores. The post object lives once; the per-user feed is a list of post ids; the follow graph answers "who follows whom":

Entity	Notes
post	post_id (time-sortable), author_id, body, media_ref, created_at. Stored once in the post store.
feed	user_id → ordered list of post_id (the precomputed feed cache; ids, not full posts).
follow	follower_id → followee_id, and the reverse index followee_id → followers, for fanout.

Step 4 — High-level design: the fanout architecture

Now the boxes. The design splits cleanly into a read path that must be fast and a write path that does the expensive work asynchronously:

• Client → feed API: the entry point for both reads and writes.
• Feed service (read path): on GET /feed, reads the user's precomputed feed from the feed cache, hydrates the post ids into full posts from the post store, applies ranking, and returns a page by cursor.
• Post service + post store (write path): on POST /post, persists the post once, then hands off to fanout.
• Fanout service (write path): asynchronously writes the new post_id into the feed cache of each follower — for normal accounts. This is the expensive step, done off the request.
• Graph / follow service: owns the follow relationships and answers "who follows this author?" for fanout.
• Ranking service: applied at read time — orders the feed by recency plus signals.
• Feed cache (Redis): a list of post ids per user; the reason the read path is fast.

Say explicitly that the read path never joins across the follow graph at request time — the feed is already assembled in the cache before the user asks. That single observation is what sets up the fanout deep dive, and naming it unprompted is a signal the interviewer is listening for.

Deep dive: fanout-on-write (push) versus fanout-on-read (pull)

This is the first decision that actually decides the round. When do you do the work of assembling a feed — when the post is written, or when the feed is read?

Model	How it works	The catch
Fanout-on-write (push)	When you publish, write the post id into every follower's precomputed feed cache immediately.	Reads are instant (just read your cache), but writes are expensive — one post means one write per follower, which explodes for accounts with millions of followers.
Fanout-on-read (pull)	At read time, fetch recent posts from everyone the user follows and merge them into a feed on the fly.	Writes are cheap (store the post once), but reads are expensive — assembling a feed means a scatter-gather across everyone you follow on every refresh.

Pick push as the default and say why in one line: the feed is read far more than it is written and must load fast, so you pay the cost once at write time and keep the read path to a single cache lookup. Pull is the right tool only where push breaks.

So where does push break? Exactly where a post has a huge number of followers. Fanning one post out to 100M follower caches on write is a write storm — it saturates the fanout workers, delays every other user's post, and writes to tens of millions of feeds that may never be read before the next refresh. That is the celebrity problem, and it is the next deep dive.

"Push or pull — which do you pick, and why?" Push by default, because the feed is read-heavy and latency-sensitive, so you move the work to write time and keep reads to one cache read. But not for everyone — the accounts with enormous followings are pulled, because pushing their posts is a write storm. The hybrid is the real answer.

System Design
HLD · Social Media Feed · 60 min
Design a news feed out loud, with follow-ups

Practise on Zynter →

Deep dive: the celebrity problem and hybrid fanout

This is the decision that separates a senior answer from a textbook one. A pure push design has one fatal case: the mega-account.

Why pushing a celebrity post fails. When an account with 100M followers posts, fanout-on-write has to insert that post id into 100M feed caches. Those writes compete with every normal post's fanout, the write latency for everyone spikes, and most of that work is wasted because only a slice of those followers will refresh before the post is stale. You cannot push your way out of a follower count that large.

So don't push for them. The hybrid answer is per-account: for the vast majority of accounts — the ones with a normal number of followers — you push (fanout-on-write), so their followers' feeds are precomputed and reads stay instant. For the handful of mega-accounts, you don't fan out on write at all — their posts are pulled at read time. When a user requests their feed, the feed service reads their precomputed (pushed) feed from the cache and fetches the recent posts of the few celebrities they follow, then merges the two into the final ranked feed.

This is the senior move, and the reasoning is what earns the points: you are pushing for the many cheap accounts and pulling for the few expensive ones, so you pay the write cost only where it is small and pay the read cost only where it is unavoidable. The merge at read time is bounded — a user follows only a handful of celebrities — so it stays fast.

"A user with a hundred million followers posts — walk me through what happens." You do not fan that out on write. The post is stored once; it is not written into 100M feeds. Instead, every follower pulls that author's recent posts at read time and merges them into their pushed feed. Pushing it would be a write storm; the hybrid pulls it.

System Design
HLD · Celebrity problem · 60 min
Defend hybrid fanout out loud

Practise on Zynter →

Deep dive: feed store, ranking, and caching

This is the decision that makes the under-a-second number real. The read path has to touch almost nothing on disk.

The feed cache. Each user's feed is a list of post ids held in Redis — not the full posts, just the ids in ranked order. Fanout-on-write pushes ids into these lists; a read is a single cache lookup for one page. The full post objects live once in a separate post store (a wide-column or key-value store, partitioned by post_id), and the feed service hydrates the page of ids into posts only for the slice being returned. Storing ids, not copies of the post, is what keeps the fanout write cheap and the cache small.

Ranking. A reverse-chronological feed is the simplest version and a fine starting point. A real feed applies a ranking service at read time that scores candidate posts on recency plus signals — engagement, affinity to the author, post type — and orders the page by that score. Ranking at read (over a bounded candidate set from the cache plus the pulled celebrity posts) keeps the write path simple and lets the ranking model change without rewriting every stored feed.

Pagination and hot feeds. The feed is paginated by cursor, not page number — the client sends the last post id or timestamp it saw and gets the next slice, which is stable under infinite scroll even as new posts arrive at the top. Hot feeds — the most active users — stay resident in cache; cold feeds can be evicted and lazily recomputed on next read.

"The feed must load in 200 ms — where does that speed come from?" From the precomputed feed cache: the read path is a single Redis lookup for a page of ids, not a join across the follow graph at request time. The expensive assembly already happened asynchronously at write time, so the read only hydrates and ranks a bounded page.

The follow-ups that decide the news feed round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

• "Push or pull — which do you pick and why?" → Push by default because the feed is read-heavy and latency-sensitive; pull only for the mega-accounts where push is a write storm. (communication)
• "A user with a hundred million followers posts — trace it." → Don't fan out on write; store the post once and let followers pull and merge it at read time. (problem solving)
• "How do you keep the feed loading under a second?" → A precomputed feed cache in Redis read as one lookup per page; no graph join at request time. (technical execution)
• "How do you rank the feed?" → A ranking service applied at read over a bounded candidate set — recency plus engagement and affinity signals — not baked into the stored order. (technical execution)
• "How does infinite scroll stay stable as new posts arrive?" → Cursor pagination on the last-seen post id, not page numbers, so new top-of-feed posts don't shift the page boundaries. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

• Days 1–2: Learn the five-step framework until it is reflex. Do the news feed end to end on paper — requirements, estimate, API, data model, the fanout boxes with a read path and a write path.
• Days 3–4: Drill the fanout deep dive: fanout-on-write versus fanout-on-read, why push is the default, and exactly where push breaks. Say each tradeoff in one sentence.
• Days 5–6: Own the celebrity problem and the read path — hybrid fanout, pull-and-merge for mega-accounts, the feed cache, ranking at read, cursor pagination. Answer each of the five follow-ups out loud.
• Day 7: A full timed 60-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the news feed is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design a news feed step by step?

Follow the five-step HLD framework. Clarify requirements (publish a post, generate a feed from accounts you follow, rank it, paginate with infinite scroll; read-heavy; eventual consistency is fine); estimate to show the hard axis is the follower distribution, not raw volume; define POST /post and GET /feed with a thin post, feed, and follow model; draw the fanout design (a fast read path over a precomputed feed cache and an asynchronous write path through a fanout service); then deep-dive the decisions that matter — fanout-on-write versus fanout-on-read, the celebrity problem and hybrid fanout, and the feed cache, ranking, and pagination. Finish on the follow-ups about latency and scale.

What is the difference between fanout-on-write and fanout-on-read?

Fanout-on-write (the push model) precomputes feeds: when you publish, the post id is written into every follower's feed cache immediately, so reads are a single fast lookup but writes are expensive. Fanout-on-read (the pull model) does the opposite: the post is stored once and the feed is assembled at read time by fetching recent posts from everyone you follow, so writes are cheap but reads are an expensive scatter-gather. Push is the default for a read-heavy feed; pull is reserved for the cases where push would be a write storm.

What is the celebrity problem in news feed design?

It is the failure case of pure fanout-on-write. When an account has tens or hundreds of millions of followers, pushing a single post into every follower's feed cache means tens of millions of writes, which saturates the fanout workers and delays everyone else's posts. The fix is not to fan those accounts out on write at all — their followers pull the posts at read time instead. Recognising this case and naming the write storm is what the interviewer is listening for.

How does hybrid fanout work?

Hybrid fanout decides push or pull per account. For the vast majority of accounts, which have a normal number of followers, you push — fanout-on-write precomputes their followers' feeds, so reads stay instant. For the handful of mega-accounts, you pull — their posts are stored once and fetched at read time. When a user requests their feed, the feed service reads their precomputed (pushed) feed and merges in the recent posts of the few celebrities they follow. You pay the write cost only where it is small and the read cost only where it is unavoidable.

How does a news feed load in under a second?

From a precomputed feed cache. Each user's feed is a ranked list of post ids held in Redis, so a read is a single cache lookup for one page rather than a join across the follow graph at request time. The expensive assembly already happened asynchronously at write time via fanout. The read path only hydrates that bounded page of ids into full posts from the post store and applies ranking, which keeps feed-read latency low even at a billion users.

How do I practise a system design interview out loud?

Reading a walkthrough is not the same as defending a design while someone interrupts. On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you talk through a shared design on the canvas, and a voice interviewer pushes with the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution, and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can read every tradeoff. The round is won on the celebrity problem and the read path.

Pick the Social Media Feed round, draw the fanout design on the canvas, and defend it out loud to a voice interviewer that keeps asking "push or pull?" and "what about the account with a hundred million followers?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Social Media Feed round →
Browse all interview tracks