Design Facebook News Feed: Fan-Out, Hybrid Feeds and Viral Posts

The scope is deliberately small: people can publish a post containing text plus an optional photo or link, build a social graph, read a feed, and like posts. Keeping the list tight lets the conversation focus on the feed itself instead of drifting into comments, ads or recommendation models, which are each a separate system.

The relationship requirement deserves attention because it has two shapes. Friendship is mutual, so both people see each other's posts, while following a page or creator is one-directional. That distinction matters later: a person has a bounded number of friends, but a page can collect an unbounded number of followers, and that asymmetry is what drives the fan-out decision.

Feed loads are the most frequent action in the product, so the first page should render in under 500 ms. That budget rules out any design that has to scan hundreds of sources on every open. It pushes us toward precomputed results that can be fetched with a single lookup.

We choose availability over strict consistency. If a friend's new post shows up in your feed thirty or sixty seconds late, nobody notices, but an error screen is immediately visible. Accepting that delay is what allows post delivery to run asynchronously in the background. The last two requirements, a 2 billion daily user read load and resilience to viral posts, are the pressures the deep dives are built around.

Assume roughly 2 billion people use the app daily and refresh their feed around 10 times apiece. That works out to around 20 billion feed loads daily, or about 230K per second on average, with peaks well above that. Reads clearly dominate.

Writes look modest at first. If around a quarter of users post once a day, we get roughly 500 million posts, close to 5.8K per second. The number that changes the design is what happens after a post is written. With an average of about 300 friends, delivering each post into every friend's feed means roughly 1.7 million feed insertions per second. Fan-out, not storage or raw post volume, is the expensive part, so the core design question becomes which authors get pushed to their audience and which get pulled on demand.

Four entities cover the model: User, Post, the Friendship or Follow edge, and Like. Keeping the relationship as its own entity makes it easy to store both mutual and one-way edges in the same graph store and query either direction.

The API has three calls. POST /posts accepts text, an optional media URL that points at already-uploaded content, and a privacy setting, then returns the new post ID. POST /posts/{id}/like records a like and returns the current count. GET /feed takes a cursor and a limit of around 20 and returns a page of posts plus the next cursor. Cursor pagination is chosen over page numbers because the feed changes constantly; an offset would shift as new posts arrive and the user would see repeats or gaps.

Requests enter through an API gateway that authenticates the caller, applies rate limits and routes the call. The write path goes to a post service, which stores the post in a posts database partitioned by post ID, emits a post-created event to Kafka and responds to the author without waiting for delivery. Decoupling the response from distribution is what keeps posting quick even for someone with thousands of friends.

Fan-out workers consume those events, look up the author's audience in the social graph and append the new post ID to each recipient's feed list in a Redis feed cache. Storing only IDs keeps each list small, and an edit to a post never requires touching millions of feed entries.

The read path is handled by a feed service. It reads this person's cached ID list, then resolves those IDs into full posts with one batched request to a post cache. That post cache also holds the latest posts from large pages and creators, which the next deep dive relies on.

Pull on read means the feed is assembled when the user opens it, by querying recent posts from every friend and merging them. Posting costs nothing extra, but at around 230K feed loads per second, each requiring about 300 lookups, the read side drowns. It also makes the 500 ms target very hard to hit.

Push on write flips the cost. Each new post is appended to every follower's precomputed feed, so a read becomes a single fetch. For ordinary users that is fine, since friend counts are capped at a few thousand. The problem is a celebrity page with 50 million followers: one post would trigger 50 million writes, many of them for people who will not open the app this week.

The hybrid approach takes the best of both. Posts from regular users and smaller pages are pushed, while posts from very large accounts are kept once in a per-author recent-posts list and merged in when a follower loads the feed. Since a typical person follows only a few such accounts, that merge touches a small number of lists. Write cost stays bounded, reads stay fast, and because delivery runs through Kafka, the author never waits for it.

Serving one feed page is a short pipeline. The feed service first reads the precomputed list of post IDs for this user, which is trimmed to a few hundred recent entries. It then fetches the recent-posts lists of any large accounts the user follows and merges the two sources into one ordering. Today that ordering is by time, but this merge point is exactly where a ranking model would later slot in without changing anything around it.

Before returning, the service filters out posts that were deleted, hidden by the user, or are no longer visible because of a privacy change. Checking visibility at read time means that tightening a post's audience takes effect on the very next load instead of waiting for a cleanup job to scrub millions of cached lists.

Finally the service hydrates the surviving IDs. Rather than issuing 20 separate lookups for 20 posts, it sends one multi-get to the post cache and gets text, author details and like counts in a single round trip. The response includes a cursor pointing just past the last item returned, so the next scroll resumes from a stable position and never repeats a post.

A viral post creates hot keys on both sides. On the read side, millions of feeds request the same post at once and the cache node that owns it becomes a bottleneck. The fix is to replicate hot entries across several cache nodes and keep a tiny in-process cache on each feed server, so most reads never leave the machine.

Likes are the write-side version of the same problem. One counter row cannot absorb that rate of increments, so the count is divided across N sub-counters, increment a random one, and sum them when reading. A further step is to send likes through Kafka and let a consumer aggregate them for a few seconds before writing a single total, turning thousands of writes into one.

When a popular entry expires, a wave of simultaneous misses can stampede the database. Request coalescing lets one request rebuild the value while the others wait for its result. All of this relies on a product judgement: a like count that is approximate and a few seconds stale is perfectly acceptable to users.

Each choice in the design has a cost that should be stated openly. Hybrid fan-out bounds write volume and keeps reads fast, but every feed load pays for a merge step. Checking privacy at read time makes changes take effect immediately, at the price of extra filtering work on each request.

Capping cached feeds at a few hundred IDs keeps memory predictable and reads quick, but a user scrolling far into the past needs a slower path that falls back to the database. Approximate like counts let the system ride out viral spikes, with the accepted downside that numbers trail reality by a few seconds. The guiding rule: push to the many ordinary authors, pull from the few huge ones, and never let one hot key carry all the load.