Design the News Feed

Understanding the problem

"Design the News Feed" built the company, and few prompts come up as often in a Meta design round. The task sounds small. A user opens the app, you show them a scrollable list of recent posts from the people and pages they follow, freshest and most relevant first. One question hiding inside that sentence decides the whole round. When someone posts, do you deliver it then, or wait until each follower asks?

Start with the numbers, because they pick the answer for you. Call it 3 billion people using the app each month, and on the order of 500 million writing a post on a given day. Against that, every one of those people opens the feed several times a day and scrolls, so reads run into the hundreds of billions a day. Reads beat writes by something like a thousand to one. Lead with that ratio early. A feed is a read-heavy product, and the design bends toward making the read cheap even when that makes the write expensive.

The Meta angle

At Meta this is almost always a Product Architecture round, not the infra-flavored System Design one. The overview lesson explains the split. Open on the data model and the API a phone calls. Reason about what the client does versus the server, and treat pagination and the user-visible scroll as first-class. You could assemble this feed from off-the-shelf cloud parts, a database, a cache, a queue, which by Meta's own rule of thumb is exactly what marks it Product rather than Infra. So lead with the schema and the endpoints, not a sharding diagram. Late in the round comes the product-judgment turn: "how would you rank this to keep people scrolling?" Engagement is the thing Meta sells, so that question is coming.

Functional requirements

Pitch a narrow scope, then pause so the interviewer can steer you somewhere else. It's a short list. A user follows other users and pages. A user creates a post. A user opens their feed and pages through recent posts from everyone they follow, newest and most relevant first.

Non-functional requirements

Attach a target to each one, because these decide the architecture. Opening the feed has to feel instant, so aim to return the first page in a couple hundred milliseconds even at p99. Reading matters far more than writing, so we'll happily spend extra work when a post is created to keep the read cheap. The feed can be eventually consistent. If your friend's post takes a few seconds to show up, nobody notices, and that small slack buys enormous headroom. Availability beats strict freshness here; a feed that is a little stale but always loads beats one that is perfectly fresh but sometimes spins.

Flag one distribution now, because a later deep dive turns on it. Follower counts are wildly lopsided. A normal person has a few hundred followers; a celebrity or a big page has tens of millions. Any plan that treats those two the same breaks on the second kind. Hold that thought.

• ~3B Monthly users. The audience the feed serves.
• ~500M Posts / day. The write path.
• ~1000:1 Read : write. Why we precompute feeds.
• ~200ms Feed-load target. First page, even the slowest 1%.

The set-up

Core entities

Before any boxes go on the board, name the objects the system passes around. Leading with them is exactly what a Product Architecture round rewards. Four matter:

Separate the post itself from the feeds it lands in. A Post is written once and read by every follower, so it lives once in a posts table keyed by post id. A FeedEntry is the opposite: cheap, disposable, and there are billions of them, one per (post, follower) pair we choose to materialize. Storing the full post text in every follower's feed would duplicate a megabyte of content across ten million feeds. So a feed holds only post ids plus a score, and the reader joins back to the posts table to get the text. Posts go in a store built for lookups by key. Reach for Cassandra, a wide-column store that spreads rows across many machines by a hash of the key. So writes never hit one hot machine. And a dead node loses nothing, because every row is copied to two others. Shard the posts table by post_id and the feed table by user_id, so one user's whole feed sits together on one shard and reads in a single trip. Spell out those keys. Interviewers ask.

API

Keep the surface thin. The feed read returns a cursor instead of a page number. A cursor is an opaque token that means "resume right after the last post I gave you," the only paging scheme that survives a feed where new posts arrive constantly. Deep dive three is entirely about why. The client sends the cursor it got last time, never a page index.

High-level design

Take the system one functional requirement at a time, building the simplest version first and calling out each bottleneck as it surfaces. The design splits along the read/write asymmetry: a write path that takes a new post and decides where it should land, and a read path that is mostly a cache lookup. In the diagram, each component's color signals its role: blue for people, violet for our services, amber for queues and streams, and green for storage and caches. The walkthrough below carries the same color on each component.

1) Create a post. The Author's client calls POST /posts against the Post service. It does two cheap things and returns: it writes the Post row to the Posts DB, and it drops a delivery job onto the Fan-out queue. The author's call does not touch a single follower's feed; it just records the post and hands the heavy lifting to the queue. So posting feels instant even for someone with a million followers, because the response comes back the moment the post is durably stored. We're punting on what that delivery job really does, and that is the first and biggest deep dive.

2) Deliver the post (fan-out). The Fan-out workers pull each delivery job off the Fan-out queue. For a normal author, a worker looks up that author's followers and writes one tiny Feed cache entry per follower: the post id and a score, prepended to each follower's feed list. This is "fan-out on write," doing the spread-out work when the post is created so that reading later is trivial. Putting it behind a queue lets the write path absorb bursts. A celebrity posting can owe ten million entries, and those simply wait as jobs while the worker fleet drains them, instead of blocking the author. The catch is that fanning a celebrity post out to tens of millions of feeds is enormous wasted work, since most of those followers won't open the app before the post is stale. Deep dives one and two size that problem and then fix it.

3) Read the feed. This path runs roughly a thousand times for every post, so it has to be cheap. The Viewer calls GET /feed and the Feed service reads their precomputed entry list straight out of the Feed cache in one in-memory lookup. It returns a page of post ids and scores already in order. Because the entries were built at write time, the common read does almost no work. The service then does two more things. It pulls the recent posts of the handful of big accounts this viewer follows directly from the Posts DB and merges them into the list by score. That is the celebrity hybrid we earn in deep dive two. Then it hydrates the page by fetching the actual post bodies for the top few ids it is about to return. Hydration is one batched read of maybe twenty posts rather than ten thousand, because we only fetch the bodies the viewer will see on this page.

4) Rank. A purely reverse-chronological feed is the naive version, and it is fine to start there. The real feed orders posts by a relevance score that goes beyond recency, so the post you are most likely to engage with sits near the top. For now treat the score as a number attached to each FeedEntry when it is written, and sort the list by it. How that score is computed, and whether it can even be precomputed, is deep dive four.

Technology choices

Up to now every box has been a category. In the room you name a concrete tool for each one and stand behind it. Meta interviewers drill the specific pick, and the follow-up is almost always a failure question: what happens when this server dies, or this queue backs up. Each pick below pairs why that category fits with how the design holds when it breaks.

• The Post service and Feed service are stateless servers behind a load balancer. No server holds anything a request needs, so any box serves any call and a dying one just drops out of the pool. All the state lives in the stores below. Boring is the goal for these.
• The Posts DB is Cassandra (or DynamoDB, the managed equivalent). A post is written once and read by key, billions of times. A wide-column store handles that well. It spreads rows across many machines by a hash of post_id, so no single machine is hot, and it copies every row to two other machines so a dead node loses nothing. The follow-up writes itself, what about a viral post hammered by reads. Because the copies can all serve reads, a hot post just gets served from whichever replica is free, and a post body never changes after it is written, so a stale copy is impossible.
• The Fan-out queue is Kafka. Delivery jobs land on a durable log split into partitions, parallel slices of the job flow, keyed by author so one author's posts stay in order. The log buys two things. A worker that dies mid-fan-out does not lose the job: Kafka remembers each worker's bookmark in the log, the offset, so a fresh worker resumes from where the dead one stopped. And when a celebrity post dumps ten million entries of work, the log absorbs the spike and the worker fleet drains it at its own pace instead of toppling. Replays after a crash can deliver a job twice, so writing a feed entry is made idempotent, keyed by (post, follower), and writing the same entry twice changes nothing.
• The Fan-out workers are a plain autoscaled worker fleet that grows with queue depth. Their one job is the follower lookup plus the per-follower write. Take the poison job, an author whose follower list is somehow corrupt and crashes every worker. After a few failed tries it lands in a dead-letter queue, a side queue for jobs that keep failing, instead of cycling forever.
• The Feed cache is Redis, holding each user's feed as a sorted list of (post id, score) capped at a few hundred entries. Redis is in-memory, so the read is microseconds, and the cap matters: nobody scrolls past a few hundred posts, so keeping more is wasted memory. The failure question is what happens when a feed isn't in the cache, either evicted or on a cold node. Because the feed is rebuildable, on a miss the Feed service reconstructs that user's recent feed from the Posts DB and refills the cache, so losing a Redis node costs latency, never data.

The feed cache and the posts DB play different roles, and it pays to keep them straight. The posts DB is the durable record, the one source of truth that must never lose a post. The feed cache is a disposable, rebuildable index built from that record to make reads fast. Treating the cache as throwaway is what lets us run it lean and in memory. Mix the two roles up, trying to make the cache authoritative or the database fast enough to serve every scroll, and you've found one of the most common ways this design goes wrong. The brand matters less than the defense here: "a Cassandra-style wide-column store" works fine, and what counts is knowing why that category fits.

Potential deep dives

This is where most of the interview signal sits. The interviewer seizes on one or two pieces and pushes hard. Below are the ones Meta returns to most, the fan-out decision above all, each scored against the tiers an interviewer grades you on.

1) Do we build the feed when you post, or when you read?

This is the heart of the problem, and the question Meta probes hardest. Building a feed is a join: take everyone you follow, take their recent posts, merge and sort. The only real choice is when to pay for that join. Pay at write time, pushing each new post into every follower's feed the moment it is created, and reads are free. Pay at read time, gathering posts from everyone you follow when you open the app, and writes are free. Size both. A read happens about a thousand times per post, so a scheme that makes reads cheap and writes expensive pays the cheap side a thousand times less often. That's the instinct. The numbers are about to complicate it.

So neither pure scheme works. Fan-out on read drowns the common case; fan-out on write drowns on the rare account with millions of followers. The lopsided follower distribution we flagged earlier is what forces the upgrade. Use a different scheme for each kind of account. That hybrid is the answer the round is built around.

The Meta angle

The celebrity problem is exactly where the interviewer will take you, because Meta lives it at a scale almost nobody else touches. A single public figure carries followers in the tens of millions. The fan-out storm isn't a thought experiment here; it happens every time one of them posts. So derive the hybrid, don't recite it. Notice the lopsided follower distribution first, then let the split fall out of it: fan-out on write breaks on celebrities, so read those at fetch time instead. Pick fan-out on write and stop, and you've capped yourself well below the bar this round sets. For the queue and worker mechanics underneath, the async processing lesson goes deeper.

2) How big is the celebrity fan-out really, and where does the work go?

Size it before solving it. Suppose 500 million posts a day come from normal accounts, and the average normal account has about 300 followers. That's 500M times 300, roughly 150 billion feed-entry writes a day from fan-out on write, which spread over a day is about 1.7 million writes a second. A Redis-backed cache fleet handles that fine when it's sharded across enough machines. Now drop in the celebrities. If a single account with 50 million followers posts, that one post owes 50 million writes. A handful of huge accounts posting in the same minute would, under pure fan-out on write, dwarf the entire normal-traffic rate in a few seconds. That arithmetic is why the hybrid exists at all.

3) How does pagination work when new posts keep arriving?

A feed is a moving target. While you scroll, new posts arrive at the top, so the list isn't a fixed array you can index into. Picture asking for "page 2" of a feed that grew by ten posts since you loaded page 1. Page 2 now starts ten posts earlier than it did, so you'd see the bottom of page 1 again, the classic duplicate-and-skip bug that plagues offset paging on live data. So page by where you are rather than by which page number.

The Meta angle

Pagination is where the Product Architecture flavor of this round shows its teeth. An infra-style interview might skip it; the Meta Product round won't. The cursor lives at the client-server boundary the product engineer owns, and getting it right is the difference between a feed that scrolls smoothly and one that flashes duplicates. Expect the interviewer to ask, in the user's words, "what happens to my scroll position when ten new posts come in while I'm reading." The crisp answer is that the cursor names a specific post rather than a page number, so new posts at the top don't disturb you. That answer separates the candidates who have built a feed client from those who have only read about one.

4) How do we rank the feed, and can the score be precomputed?

Reverse-chronological is the honest starting point, and you should name it first. Sort every feed entry by post time, newest on top; it's simple, and it's what every feed started as. The trouble is that the best post for you is often an older one. A pure time sort buries the post you'd most want to see under a pile of fresher but duller ones. Ranking reorders the feed by a relevance score that predicts how likely you are to engage. The hard part for the architecture: this score depends on both the post and the viewer, the opposite of what fan-out on write assumed.

The Meta angle

Ranking is where Meta's product-judgment turn lands, the "how would you change this to drive engagement" question the overview warned about. Nobody's asking you to invent Meta's actual ranking model. They want to see that you grasp that the score is per-viewer and read-time, and that you gather a small set of candidate posts before scoring them. They also want you to name the tradeoff: a more engaging rank versus the cost of computing it on every open, versus the risk of an echo chamber if you over-optimize for clicks. Treat ranking as a product decision with real tradeoffs, weighed where the interviewer can watch, and you've hit the senior product signal this round exists to test.

5) How does caching keep the read path fast and consistent?

The read path leans almost entirely on the Feed cache, so its behavior under stress decides whether the feed feels instant. Two questions come up. What happens on a cache miss, and how do edits or deletes stay consistent when a post lives in millions of cached feeds at once.

A miss means a user's feed list has been evicted or sits on a cold cache node, and the Feed service rebuilds it. It reads that user's follows, pulls the normal accounts' recent posts from the Posts DB and merges them with the celebrity reads. It writes the rebuilt list back to the cache and serves it. The feed cache is rebuildable from the durable posts store, the property that lets us treat it as disposable. The risk here is a cache stampede: a popular shard goes cold and thousands of users miss at the same instant, all rebuilding the same data and hammering the database together. The fix is request coalescing, also called single-flight: the first miss for a given feed starts the rebuild and every other request for it waits on that one rebuild instead of launching its own.

Consistency on edits and deletes is the subtler half. A post edited or deleted after fan-out already sits as an id in millions of feed lists. Rewriting all those lists would be a second fan-out storm, so we don't. A feed entry stores only the post id, and the body is hydrated from the Posts DB at read time. So an edit just updates the one posts row, and every feed picks it up on its next hydration at no extra cost. A delete sets a tombstone, a small "this post is gone" marker on the posts row. The feed service drops tombstoned ids while hydrating a page, so the stale pointer in a thousand caches resolves to nothing and ages out on its own. Storing pointers rather than bodies in the feed is what makes edits and deletes cheap. For the general caching patterns underneath this, the scaling reads lesson goes deeper.

What is expected at each level

That's a lot of surface area. How much of it you need to land depends on the level you're interviewing for. The design round mostly shows up at E5 and above, and it's the round that most often decides your level.

E4 (mid-level)

Mostly breadth, roughly 80/20 breadth to depth, and at E4 a design round is light or absent. Get to a working end-to-end design: a posts table, a feed cache, fan-out on write, a cursor-paged read. You should know what each box does when probed even if you don't reach the optimal version of any of them, and the interviewer will drive the deeper parts. The bar: a complete skeleton you can explain, with a few rough edges the interviewer helps you smooth.

E5 (senior)

Breadth, then real depth, roughly 60/40. You're expected to reach the celebrity hybrid on your own, naming the lopsided follower distribution and deriving fan-out on write for the many plus fan-out on read for the few before being asked. Reach for cursor pagination without prompting, and defend the posts and feed partition keys. The bar: a near-optimal design where you found the celebrity bottleneck yourself. This is the level the design round most often decides, and reaching the hybrid on your own is usually what tips it.

E6+ (staff)

Depth across several components and a widening scope, roughly 40/60. Expect questions on read-time ranking as a two-stage problem: gather a few hundred candidate posts cheaply, then score them. Expect questions on consistency when posts are edited or deleted across millions of cached feeds. Expect the stampede question, when many users miss the cache at once and how the feed rebuilds. And expect to be asked how the system degrades when the fan-out queue backs up during a major event. You're driving the conversation and reasoning about operational reality well past the happy path, including the product-judgment turn on engagement tradeoffs. The bar: you lead, and the interviewer steps in to redirect rather than to rescue.