Design a News Feed

Step 1. Scope the prompt

"Design a news feed" means the home timeline: the stream of recent posts from everyone a user follows.

Functional requirements: a user can post. A user can follow other users. A user can open their home feed and see recent posts from the people they follow, newest first. We will skip likes, comments, and ads, and say so out loud.

Non-functional requirements: two things shape everything. First, this is heavily read-heavy: people scroll their feed far more often than they post. Second, one post may need to reach a huge number of followers. A user with ten million followers posts once, and that single post belongs in ten million home feeds. How you handle that one fact decides the whole design.

Step 2. Napkin math

Put rough numbers on it. Say 100 million daily users. Each opens their feed 10 times a day, so that is a billion feed reads a day, around 12,000 reads per second on average and several times that at peak.

Posts are rarer. Say each user posts twice a day: 200 million posts a day, a few thousand per second. Small on its own.

But here is the number that matters. Each post fans out to every follower. If the average user has 200 followers, 200 million posts a day becomes 40 billion timeline writes a day. The reads are big, but the fan-out writes are the real mountain. That single fact, not the read count, is what your design has to survive.

Step 3. The API and data model

Three operations:

POST /posts creates a post. POST /follow records that user A follows user B. GET /feed returns the home timeline for the logged-in user, newest first, with paging.

The data is three simple things: a posts table (who posted what, and when), a follows table (who follows whom), and a home timeline for each user, which is the list of post IDs that should appear when they open the app.

That last one is the key idea. The home timeline is a precomputed list per user. The whole design question is really just: when do you build it, and how?

Step 4. The core decision: push or pull

There are two ways to build a home timeline, and this is the heart of the interview.

Fan-out on read (pull). Do nothing when someone posts. When a user opens their feed, look up everyone they follow, fetch each person's recent posts, and merge them on the spot. Simple to write, but slow at read time, and reads happen constantly. For a user following 1,000 people, every feed open becomes 1,000 lookups.

Fan-out on write (push). When someone posts, immediately write that post into the home timeline of every follower. Reading the feed is then trivial: just return the user's prebuilt timeline. Reads become instant. The cost moves to write time, where one post may mean millions of timeline writes.

Since the system is read-heavy, you want reads to be cheap. So the default answer is fan-out on write: do the heavy work once, when posting, so every later read is fast.

Step 5. Make the fan-out async

Fan-out on write has a trap. If a user posts and you write to all their followers' timelines right then, while they wait, the post could take minutes for someone popular. The user stares at a spinner. That is not acceptable.

The fix is to do the fan-out in the background. When someone posts, the feed service does two quick things: save the post, and drop a "fan this out" job into a queue. Then it returns success immediately. The user's post feels instant.

Behind the scenes, a pool of workers pulls jobs off the queue and writes the post into each follower's timeline, steadily, in parallel. If a burst of posts arrives, the queue absorbs it and the workers catch up. To go faster, add more workers.

This is exactly what you will build: posting drops the work on a queue, and workers spread it out so the post never blocks.

Step 6. The celebrity problem, then build it

Close like a senior by naming the famous flaw. Pure fan-out on write breaks for celebrities. A user with fifty million followers posts, and that is fifty million timeline writes for one post. Do that for every celebrity post and the workers drown.

The standard answer is a hybrid. Use fan-out on write for normal users, where it is cheap. For the small number of celebrities, skip the fan-out and instead pull their recent posts at read time, merging them into the feed when a follower opens the app. Most users get instant reads, and the handful of huge accounts never trigger a write storm.

Tradeoffs to name: push gives fast reads but heavy writes and wasted work for inactive users. Pull gives cheap writes but slow reads. The hybrid takes the best of each.

Now build the engine that makes push safe: the async fan-out. Fan-out work arrives at 80 jobs per second. Each worker handles 20 per second. Buffer the work in a queue and add enough workers so no post ever waits.