Imagine a newspaper that writes a completely different edition for each of its 3 billion readers, tailored to what each reader cares about, updated continuously throughout the day, and delivered within half a second of each reader opening their phone. That is Facebook’s News Feed - and the engineering challenge of making it work at this scale is one of the most interesting problems in distributed systems.

When someone with 200 million followers posts a photo, the naive implementation would be to write that post ID into 200 million users’ feed lists simultaneously. At 200 million writes, that is a write storm that would overwhelm any database. But if you do nothing at write time and pull from 200M followers at read time, a single feed request becomes a scatter-gather query to millions of rows. Neither extreme works.

The tension is between write amplification and read latency. Push-on-write (fan-out) makes reads fast but writes explosive. Pull-on-read makes writes cheap but reads slow. The real system uses a hybrid: regular users get fan-out on write, celebrities use pull-on-read, and a ranking layer stitches the two paths together at read time.

On top of the distribution problem, there is the ranking problem. A chronological feed was the original design, but engagement drops dramatically when stale or irrelevant posts appear first. The ranking model must score hundreds of candidate posts per user in milliseconds, using personalized affinity signals that vary for every user-author pair. We need to solve for: write fan-out without 200M database writes, read latency under 500ms with ranking applied, and per-user personalization that does not require real-time computation for all 3 billion users simultaneously.

Requirements and Constraints

Functional Requirements

• Generate a personalized, ranked news feed per user on request
• Accept post creation from any user and propagate to followers
• Show posts from followed users, groups, and pages
• Support likes, comments, and shares that update engagement signals
• Paginate the feed using a cursor so users can scroll infinitely
• Support feed refresh to show new posts at the top

Non-Functional Requirements

• 3 billion monthly active users, ~1 billion daily active users
• Feed read latency: p99 under 500ms
• Post fan-out: propagate a regular user’s post to all followers within 60 seconds
• Celebrity post fan-out: not applicable - use pull model
• Ranking: score and order up to 500 candidate posts per feed request
• Feed cache: top 500 post IDs per user, TTL 7 days
• Write throughput: ~500M posts/day = ~6,000 writes/second average

Constraints

• Celebrity threshold: users with over 100,000 followers use pull model to avoid write amplification
• Feed cache is eventually consistent - a post may take up to 60 seconds to appear
• Feed ranking re-runs on every page load - cached post IDs, not cached rankings
• Offline users’ caches may be stale or cold on first login after inactivity

High-Level Architecture

The system has two primary data paths: write path (user creates a post) and read path (user requests their feed). These paths share storage but are designed to scale independently.

The Post Write Service accepts new posts and writes to the Post Store (sharded MySQL). It publishes a post event to the fan-out Kafka topic. Fan-out Workers subscribe to this topic, check whether the author is a celebrity, and either push the post ID to each follower’s Redis feed cache or skip fan-out for celebrities.

At read time, the Feed Read Service fetches the user’s pre-computed feed list from Redis. For any celebrities the user follows, it fetches recent posts from those timelines directly (pull model). The merged candidate list goes to the Ranking Service, which scores each post using a lightweight ML model and returns the top 20 posts for this page. The Social Graph Service (backed by Facebook’s TAO - the graph database) provides follower/following relationships.