Facebook Feed System Design (Ranking & Scale)
Scenario
From the user’s side, the home feed is simple: open the app, scroll, see posts from people and pages you follow—ideally ranked or at least fresh enough that the product feels alive. From your side as the engineer, the hard part is the shape of the traffic: reads dwarf writes by orders of magnitude, the follow graph is huge and skewed, and a handful of accounts have follower counts that break any naive “fan this post out to everyone” or “at read time, join every account I follow and sort by time” story. In practice you separate durable post storage from feed assembly, you think about fan-out on write versus pull on read versus a hybrid, you shard mailboxes or candidate sets, you put ranking behind a latency budget, and you say what degrades when queues back up or the ranker slows down. The interview is basically: walk that path like you have shipped it, not like you memorized a diagram.
You’re designing the home feed for a large social network: updates from people and pages you follow, ordered by relevance or recency, paginated, and fast enough that scrolling feels instant. At interview scale, the interesting part is not the ER diagram—it’s how you avoid doing unbounded work per user per swipe.
Constraints
Create posts (text, links, media); follow/unfollow; home feed with pagination; reactions and comments on posts; hide/block; optional “most recent” vs “top stories”.
Global audience; feed p95 under 300ms for typical users; high availability; ranking pipeline may lag seconds behind writes.
1B+ MAU, 500M+ DAU; hundreds of millions of posts per day; feed reads orders of magnitude higher than writes; some accounts have 100M+ followers.