Design a News Feed

Diwali morning, 8 am. Meena opens the app for the first time since last night, and her 400 connections have posted about 2,000 things since then: her cousin Asha’s wedding photos from 3 am, forty match updates from cricket pages, sale posts from shops she followed years ago. In newest-first order, Asha’s photos sit on screen nine, and Meena never gets there. Last year the team fixed that by re-ranking on every scroll. Page 2 then repeated three posts from page 1, and at the 9 pm peak the ranking fleet ran out of capacity and feeds stopped loading. This chapter builds a feed that ranks well, pages cleanly and stays up.

The product: the news feed of a social app with 300 million daily users. People see posts from friends, pages and groups, ordered by what they are most likely to care about, and the feed keeps loading as they scroll. You are designing how the feed is gathered, ranked and paged.

Design a Microblog built a timeline: posts from accounts you follow, newest first. A news feed draws on the people, pages and groups you are connected to, but orders posts by how likely you are to care about them. It mixes text, photos, videos and links, and it keeps loading as you scroll.

Think of a friend who reads every newspaper in town and hands you the five stories you would actually want. That friend is the ranking, and in a feed ranking is the feature. Three things make it harder than a timeline. The order depends on the viewer, so no two people share a list. It depends on signals that change by the minute, such as how many likes a post has collected. And Meena still expects her scrolling to stay stable while all of that moves underneath.

The scope below keeps ranking and paging at the centre.

The items on the right either exist already or plug into fixed slots, so none of them changes how the feed is built.

A feed is judged on feel: the first screen must appear quickly and scrolling must never stall. The requirements turn those feelings into numbers.

• Fast first page. The server returns the first 10 posts in under 300 ms at p99, the time that 99 of every 100 requests beat; images then load from a nearby CDN.
• Smooth scrolling. Each later page returns in under 100 ms, so the next screen is ready before the thumb gets there.
• Fresh enough. A friend’s new post becomes eligible for your feed within about a minute.
• Degrade, do not fail. If ranking is slow or down, show a feed in time order rather than an error.
• Privacy is checked at read time. A post shared with friends only must never reach someone who has since been unfriended.

The assumptions below drive every estimate.

Together they give the request rate, by the method of Back-of-the-Envelope Estimates: 300 M × 8 sessions × 3 pages = 7.2 B page loads a day, about 83,000 a second on average and roughly 250,000 a second around the 9 pm peak (3×). The next page asks whether the precomputed data behind those pages fits in memory.

A ranked feed needs something to rank. For each user we keep a candidate pool: recent posts from their connections that they have not seen yet. Meena’s pool holds the posts her 400 connections made since she last looked. Pools are kept up to date as posts are created and ranked from at session start, so first check that they fit.

Ten terabytes of memory is affordable at this size but not free. Keep in memory only the pools of people who open the app most days, and move the rest to an SSD-backed store, where a read costs a millisecond or two instead of a fraction of one. A pool nobody has read for a week can be dropped and rebuilt on the next visit.

The other estimates fill in the rest of the load.

Two rows shape the design: scoring work, which decides when ranking runs, and media bandwidth, which must go through Content Delivery Networks, never through feed servers.

With the load known, the API stays small: fetch a page, ask whether anything new has arrived, and report what the user saw or hid. All the ranking happens behind these calls.

GET  /v1/feed?limit=10                    -> 200 {"items": [...], "next_cursor": "c2Vzcz..."}
GET  /v1/feed?limit=10&cursor=c2Vzcz...   -> 200 {"items": [...], "next_cursor": "..."}
GET  /v1/feed/new-count?cursor=c2Vzcz...  -> 200 {"count": 4}
POST /v1/feed/impressions  {"post_ids": ["p81", "p77"], "session": "s_3f"}     -> 204
POST /v1/feed/hide         {"post_id": "p81", "reason": "see_less_from_author"} -> 204
PUT  /v1/posts/{post_id}/reactions/me      {"type": "like"}                     -> 204

Each item carries the post, its author, counts and media URLs that point at the CDN.

The cursor is opaque to the client: the server packs into it everything it needs to continue the same ranked list, which the paging deep dive explains. Impressions, the record of which posts actually appeared on screen, go in batches every few seconds rather than one call per post. They feed ranking and stop the app from showing Meena the same post again tomorrow.

Each item in a page carries everything the phone needs to draw one card:

Media URLs are sized for the screen. A phone 1080 pixels wide gets the 1080-pixel copy, about 150 KB, not the 4000-pixel original, and private posts get signed CDN URLs that expire after a few minutes. Videos start muted at a low quality from short segments, as Design a Video Streaming Platform describes. The next page covers the data behind these calls.

The feed reads data that other services own: posts, people and the connections between them. It adds two things of its own, the candidate pool per user and an event log of what users did.

Each kind of data goes where its access pattern fits:

Only the pools are written on every new post; everything else is read-mostly or append-only. Affinity is a number from 0 to 1 for each pair of user and connection: how close they seem, from likes, comments, messages and profile visits over the last few weeks. Meena’s affinity to Asha is about 0.9. It changes slowly, so a daily batch job over the interactions log is enough.

A pool has a simple life cycle:

• Fills: a fan-out worker appends a post id when one of your connections posts.
• Drains: impressions mark entries as seen, and entries older than about three days expire.
• Stays small: once a pool holds 500 entries, the lowest-affinity entries go first, so someone with 5,000 connections keeps the people closest to them.

Those pieces form a pipeline. The first stage runs when posts are created; the rest run when Meena opens the app. Pools fill exactly as Design a Microblog fills timelines: fan-out on write for most authors, pull at session start for pages above a follower threshold, chunked jobs and all. This chapter does not repeat that machinery; its depth goes to what happens after the pool is full.

The scene follows Meena’s first page, her second, and an evening when ranking falls behind.

The first page pays for ranking once, and later pages are cache reads. When ranking misses its budget, the feed falls back to time order instead of failing, and feed servers send small JSON while the CDN sends the heavy bytes, so 500 Gbps of media never needs 500 Gbps of feed servers.

The pipeline’s first stage decides what can be ranked at all. So far every candidate came from the viewer’s connections; most feeds mix in other sources, each producing a short list at session start that joins the pool before ranking.

Each candidate carries its source, and the ranker scores all of them on the same scale. Re-ranking rules then cap each source, for example at most 3 recommended posts in every 10, so Asha is never crowded out by strangers.

Cold start is the empty-pool problem. A new user has no connections, no affinity and no history, so start with trending posts in their region and language, ask for a few interests at sign-up, and suggest people from their contacts if they allow it. Their first likes and hides reshape the very next session. A new post has the same problem: with few impressions its engagement rate means little, so show it to a small sample first and widen if people respond. Those impressions are the next page’s subject.

Ranking learns from what people saw, so every post that appears on screen produces an impression event. 7.2 B pages a day × 10 posts is 72 B impressions, about 830,000 events a second, the biggest write stream in the system. New posts arrive at under 600 a second; impressions arrive more than a thousand times faster.

Nobody reads these events one by one, so they never touch a database. The impressions endpoint checks a batch, appends it to a partitioned, replicated log, as in Publish-Subscribe, and returns 204. Phones send one batch every few seconds, so the endpoint handles requests, not single events. Three consumers read the log at their own pace:

One write feeds three jobs, and none of them slows the phone. Size the log from bytes, not events: at about 100 bytes an event, that is roughly 83 MB/s on average and 250 MB/s at the evening peak. One log partition handles about 10 MB/s, so the peak needs 25 partitions; plan for about 50 to keep 2× headroom for spikes and replays. Key them by user id, so one user’s seen marks stay in order on one partition.

Think of a restaurant. It can cook every dish before opening, cook each plate when ordered, or prepare ingredients in the morning and cook when the table sits down. A feed has the same three choices, and the choice decides latency, freshness and the bill.

The third column wins for most products. Keep pools up to date as posts are created, rank once when a session starts (roughly one sitting with the app), cache that ranked list for about 15 minutes, and serve every scroll from it. There are 7.2 B page loads but only 2.4 B sessions a day, so this does a third of the scoring of ranking per page, and it never reshuffles posts under Meena’s thumb.

The advice flips at the edges. A "latest" view needs no ranking at all. A short-video app where each swipe changes what the viewer wants may re-rank every few items, and pays for it. And users who open the app every morning at 8 can have their first list built a few minutes earlier, so their first page is instant, while monthly visitors get theirs on demand. The next page sets the budget for that per-session work.

Ranking per session moves the cost to one moment, the first page, so that moment needs a budget. 2.4 B sessions a day is about 28,000 session starts a second, and about 83,000 at the 9 pm peak; at 500 candidates each, that is about 42 M scores a second at the peak.

The first page must return in 300 ms at p99, and each step gets a share of it:

Scoring takes the largest share, so it gets a hard timeout. If it runs out, serve the candidates in time order and rank properly on the next session: a plain feed now beats a perfect feed in three seconds. The cached list itself is cheap: 500 ids × 8 bytes = 4 KB a session, and 83,000 starts a second kept for 15 minutes is about 75 M lists, roughly 300 GB.

Three cases need rules. A user who reopens within 15 minutes continues the same list. A pull to refresh re-ranks, but at most once a minute per user, so an impatient thumb cannot multiply the load. And new candidates that arrive mid-session wait behind a "new posts" prompt rather than reshuffling the list.

The budget says when scoring runs; this page says what it computes. Each candidate gets a score from a handful of signals, measurable facts about the viewer, the author and the post, and the feed shows the highest scores first. Five signals do most of the work:

• Recency: how old the post is.
• Affinity: how close the viewer is to the author, such as 0.9 for Meena and Asha.
• Engagement: how others reacted, relative to how many saw it.
• Content type: what this viewer tends to engage with, such as videos watched to the end.
• Negative feedback: hides, "see less" and reports, which count against.

Engagement must be a rate, not a count. 120 likes from 1,000 viewers (12%) beats 2,000 likes from 100,000 viewers (2%), because the first post is landing with the people who see it. The rate is compared with other recent posts to get a value from 0 to 1, and a post with only a few views gets a neutral value until more arrive. That rate is why the impressions stream exists.

A simple, explainable score multiplies a weighted sum of signals by a time decay, so every post loses half its score every 6 hours:

Here are three posts from Meena’s 8 am pool:

Time order would show C, B, A, with Asha last. The score shows B, A, C: the fresh but dull post drops, and Asha’s photos move up despite being five hours old. Change the weights and the feed’s personality changes, which is why new weights go to a small share of users first. Re-ranking then adds variety: no two posts in a row from one author, and a cap on videos per page.

A ranked list is only useful if Meena can scroll through it cleanly, and feeds change while she reads: new posts arrive, scores move, and she hides things. Offset pagination, "give me items 11 to 20", counts positions in a list that will not hold still.

Offsets count positions in a list that keeps moving, so new posts cause repeats and removed posts cause silent gaps. A cursor names a position in one frozen list, so later changes cannot move it. The next page shows what goes inside that cursor.

A cursor is an opaque token that says where you are in a particular list. In the microblog’s timeline it can be the last post id shown, because that list is sorted by id. A ranked list is not. The last score shown fails too: scores change between pages, and ties make "after 0.45" ambiguous. So the cursor holds the id of the session’s ranked list and a position in it.

The server signs it so clients cannot edit it or read another user’s list, and because clients never look inside, the server can change its contents later without breaking old app versions.

Lists expire, so the cursor must survive that. If list L7 is gone when page 2 is requested, the server ranks a new list and skips any post ids already shown in this session, which it keeps in a small seen set: about 30 ids for three pages, a few hundred bytes. Meena sees no repeats, even across a rebuild.

Freshness works with the frozen list, not against it. While the app is open, it calls new-count every minute or two and shows "4 new posts". It inserts them only when Meena taps or pulls to refresh, which starts a new list at position 0, because reshuffling under someone’s thumb loses their place.

With ranking and paging in place, the next question is what happens when the parts they depend on fail.

Every dependency of the feed can be slow or down, and the rule for each is the same: return something useful within the time budget. The table lists each failure, what the user sees, and how the design copes.

Almost every failure ends in the same place, a plainer feed in time order, which is why that fallback is designed in from the start rather than bolted on.

A feed that never fails can still fail its users. The big product trade-off is engagement against variety: a feed tuned only for clicks fills up with one kind of post. The re-ranking rules help, and so do a few slots for newer authors, so the system keeps learning what Meena likes.

Clicks alone are a poor target because they reward bait, so every ranking change runs as an A/B test: a small random share of users gets the new version, and a mix of metrics is compared with everyone else before it rolls out.

A change that lifts clicks but also lifts hides, or lowers 30-day retention, is not shipped. In production, three signals show whether the system itself is healthy:

Media egress through the CDN dominates the bill: about 500 Gbps on average, some 160 PB a month. Ranking compute comes second, which is why ranking once per session instead of once per page matters.

Here is the whole answer on the interview clock: about 40 minutes of design once introductions are done.

Pick the deep dive from the interviewer’s questions. Latency or cost: when ranking runs. Why one post beats another: the score and its signals. Infinite scroll or duplicates: cursors. A brand-new user: candidate sources and cold start.

Interviewers often change the problem halfway to see whether the design bends or breaks. Answer each one before opening it.