Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Post writes: 2B DAU with roughly 1.8 posts per day per active poster. That is 3.6B new posts per day, or approximately 42K writes per second. During peak hours (evenings in major time zones), expect 2-3x spikes to 100K+ writes per second.

Read-to-write ratio: Approximately 3:1 on raw request count, but the asymmetry is deeper. Each write produces one database insert. Each read must consider posts from the user's entire social graph (hundreds of sources). Without precomputation, each read would require hundreds of database queries.

Post storage: Average post size is roughly 2KB (text, metadata, media references, actual media lives on CDN). At 3.6B posts per day, that is 7.2TB of new post data daily, or roughly 2.6PB per year. Cassandra handles this with horizontal scaling.

Codemia

Problem

Editorial

Design Facebook’s Newsfeed

Overview

Design a personalized news feed system that aggregates posts from friends, pages, and groups, ranks them using ML models, and serves results in under 200ms to billions of users.

System requirements

You open Facebook and see 20 posts. Behind those 20, the system evaluated 1,500 candidates from your 500 friends and 200 followed pages, ranked them with an ML model, and returned results in under 200ms. The real challenge is not showing posts. It is deciding which 1,500 candidates to even consider when you follow 700 sources and each posted multiple times today.

Functional

Personalized feed: Aggregate posts from friends, followed pages, and joined groups into a single ranked feed. Each user sees a different ordering based on their interaction history.

Post creation: Users publish text, images, videos, and link previews. Each post is immediately visible to the author and eventually appears in followers' feeds.

Reactions and comments: Users engage with posts through reactions (like, love, angry) and threaded comments. Engagement signals feed the ranking model.

Real-time updates: Online users receive notifications when new posts are available. The client decides when to fetch rather than auto-refreshing, which prevents jarring feed shifts mid-scroll.

Feed ranking: Posts are ordered by predicted relevance, not reverse chronology. The ranking model weighs recency, engagement probability, content type preference, and relationship strength.

Non-Functional

Low latency: Sub-200ms feed rendering. Users perceive anything above 300ms as sluggish. The feed is the first thing they see on app open.

Massive scale: 2B+ daily active users. The system must handle 100K+ feed reads per second and 40K+ post writes per second simultaneously.

Eventual consistency: A 3-5 second delay between posting and appearing in followers' feeds is acceptable. Strong consistency across 2B users would require distributed transactions that are impractical at this scale.

High availability: 99.99% uptime. A blank feed is never acceptable, degraded feeds (stale, unranked) are always preferable to no feed.

Graceful degradation: When any component fails, the system falls back to a less optimal but functional state rather than returning errors.

Scope Control

Focus on feed generation, fan-out strategy, and ranking pipeline, these are the core engineering challenges. Exclude ad serving, Marketplace, Stories, and Messenger integration. Mention these as separate systems that inject content into the feed pipeline but are not part of it.

Capacity estimation

The read-write asymmetry reveals the architecture. 2B daily active users generating 3.6B posts per day means 42K writes per second. But 10B+ feed fetches per day means 120K reads per second. Each read touches hundreds of sources. This asymmetry is why precomputed feeds exist. You cannot merge 500 sources in real time at 120K requests per second.

Traffic

Post writes: 2B DAU with roughly 1.8 posts per day per active poster. That is 3.6B new posts per day, or approximately 42K writes per second. During peak hours (evenings in major time zones), expect 2-3x spikes to 100K+ writes per second.

Feed reads: Each user opens their feed 5+ times per day, each time fetching 20-50 posts across multiple scroll loads. That is 10B+ feed requests per day, or roughly 120K reads per second sustained, with peaks at 300K+.

Read-to-write ratio: Approximately 3:1 on raw request count, but the asymmetry is deeper. Each write produces one database insert. Each read must consider posts from the user's entire social graph (hundreds of sources). Without precomputation, each read would require hundreds of database queries.

Storage

Post storage: Average post size is roughly 2KB (text, metadata, media references, actual media lives on CDN). At 3.6B posts per day, that is 7.2TB of new post data daily, or roughly 2.6PB per year. Cassandra handles this with horizontal scaling.

Feed cache: Each active user's feed cache stores 200 post IDs with ranking scores. At 8 bytes per post ID plus 8 bytes for the score, that is roughly 3.2KB per user. For 500M highly active users, the feed cache totals approximately 1.6TB in Redis, split across a cluster.

Social graph: 2B users averaging 500 friend and follow edges each. At 16 bytes per edge (two user IDs), the raw graph is roughly 16TB. Indexed and replicated, the social graph service requires roughly 50TB of storage.

Bandwidth

A single feed response returning 20 post IDs with scores is roughly 500 bytes. At 120K requests per second, that is 60MB/s for feed metadata alone. Full post content (fetched separately with media URLs) adds significantly more, but CDN handles the heavy media delivery.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10