Facebook Feed

Assume 2B daily active users. Each user makes about 20 feed page requests per day across app opens, refreshes, and infinite scroll. Each feed page returns 25 items. The system receives 300M new posts per day, 35 percent of posts include media, and the average media original is 2 MB before derived thumbnails and video renditions.

Assume 95 percent of posts come from ordinary users, pages, or groups that can be pushed to an average of 300 recipient feed caches. The remaining 5 percent are high-degree producers and are pulled at read time. Engagement volume is 20B actions per day. Cache each active user with about 500 ranked post ids, storing 16 bytes per id plus metadata and replication overhead.

• Feed reads: 2B users times 20 feed page requests per day is 40B requests per day. 40B divided by 86,400 seconds is about 463K average read QPS. A 10x regional peak gives about 4.6M read QPS.
• Items served: 40B feed pages times 25 items is 1T feed items returned per day. Ranking cannot score the entire universe online for each request, so the system must use candidate pruning and cached ranked post ids.
• Post writes: 300M posts per day divided by 86,400 seconds is about 3,500 average post writes per second. With a 10x peak, plan for about 35,000 post writes per second.
• Hybrid fanout: 95 percent of 300M posts is 285M push-fanout posts. 285M times 300 average recipients is 85.5B feed-cache inserts per day, or about 990K inserts per second average before batching.
• Engagement writes: 20B actions per day divided by 86,400 seconds is about 231K action writes per second average, with multi-million QPS peaks for viral events.
• Feed cache: 2B users times 500 cached post ids times 16 bytes is 16 TB raw ids. Add rank scores, cursors, timestamps, model versions, Redis or key-value overhead, and replication to reserve roughly 50 to 100 TB.
• Action storage: 20B actions per day times 200 bytes is 4 TB raw per day. Thirty days is 120 TB raw; with replicas, indexes, and compaction overhead, plan for about 500 TB of hot action data.
• Media: 35 percent of 300M posts is 105M media posts per day. At 2 MB each, originals require about 210 TB per day before derived formats, thumbnails, CDN cache, and object-store replication.

• social_edges.source_id, edge_type supports candidate generation from the viewer outward.
• social_edges.target_id, edge_type supports reverse fanout to followers when a producer posts.
• posts.author_id, created_at supports pulling recent posts from high-degree pages, groups, and creators.
• feed_cache_entries.user_id, position supports fast ordered reads of cached ranked post ids.
• engagement_events.post_id, created_at supports post-centric counters, comment fetches, and ranking features.
• engagement_events.actor_id, created_at supports viewer history, seen-state, and dedupe.
• media_objects.content_hash helps deduplicate uploads and match known-bad media.

A feed item references a post id. The post references an author and optional media ids. Social edges define whether the author or container is eligible for a viewer. Engagement events reference both actor and post. The feed serving path should not join these tables directly in a relational sense; it should perform bounded point lookups and batched hydration from stores optimized for each access pattern.

Use a graph or adjacency-list store for social edges, partitioned by source id and replicated by region. Use a wide-column or key-value store for posts, partitioned by post id with secondary views by author and time. Use Redis, Memcached, or a custom distributed cache for feed_cache_entries, storing compact ranked post-id arrays per user. Use Kafka or Pulsar plus a columnar lake or OLAP store for engagement events, with nearline feature stores for ranking.

Media belongs in object storage, not in the post database. Store originals and renditions in an object store, serve them through CDN, and keep only ids, moderation state, hashes, and URLs in metadata stores.

A chronological feed is easy to explain but weak for a large social network. A user may follow hundreds of friends, pages, and groups. Some sources post rarely and are highly important; others post frequently and are low value. The feed must rank for predicted value, not just recency.

A mature ranker uses many signals: relationship affinity, post freshness, content type, media quality, comments from close friends, click and dwell history, hides and reports, author quality, group membership, language, location, device, and explicit preferences. The serving system must hydrate these features quickly and degrade safely if some features are stale.

The strongest interview answer separates candidate generation from ranking. Candidate generation narrows millions of possible posts down to hundreds or thousands. Ranking scores those candidates with a latency budget. Aggregation then enforces dedupe, diversity, seen-state, privacy, ad slots, and policy constraints.

Pure pull means every feed read scans recent posts from all friends, pages, and groups. That is too slow for users with large graphs and too expensive for billions of reads. Pure push means every post is inserted into every follower cache. That explodes for celebrities, major pages, and large groups.

Hybrid fanout is the usual answer. Push ordinary posts to follower feed caches because the recipient set is bounded and reads become cheap. Pull high-degree sources at read time because their fanout would be massive. The producer can be classified dynamically using follower count, posting rate, engagement velocity, recipient activity, and queue pressure.

Hybrid fanout also improves freshness. A close friend's post can appear quickly through push, while a viral public page can be pulled and ranked when the user opens the app. The candidate service merges both sets and removes duplicates before scoring.

Candidate generation must be bounded. The system reads the viewer's active friends, close friends, pages, groups, recently interacted authors, and friend-of-friend or recommendation edges. For each source, it takes a small number of recent or high-quality posts and applies early filters for privacy, blocks, mutes, language, and policy.

Friend-of-friend is powerful but dangerous if unconstrained. It can discover socially relevant content, but it expands the graph rapidly and can leak private context. Use explicit public interactions, privacy-safe recommendations, and caps per reason. Keep explainable candidate reasons such as close friend commented or popular in group.

For groups, membership and moderation state are essential. A public group may allow broad discovery, while a private group requires strict membership checks during candidate generation and final hydration.

The feed cache should store ranked post ids, not full post bodies. Full bodies change due to edits, deletes, privacy changes, comment counts, and media processing. Storing ids lets the serving path re-check visibility and hydrate current metadata.

Freshness is handled with short TTLs, cache refresh watermarks, and incremental insertion. New close-friend posts can be inserted near the top. Older cached items can remain for pagination as long as the cursor identifies the rank version. If the user pulls to refresh, the system can generate a new head while preserving scroll stability for older pages.

Seen-state prevents repetition. The client reports impressions and visible items, and the server records a dedupe window. The aggregator filters recently seen posts, but can still resurface important updates if comments or shares make them newly relevant.

Ads are not simply appended after organic ranking. The feed must reserve eligible slots, request ad candidates, score them for relevance and business constraints, then interleave them without damaging user experience. Frequency caps, advertiser budgets, user preferences, sensitive categories, and policy checks apply.

The organic ranker and ads ranker can be separate, but the final aggregator must compare them through a common utility function or slot policy. It should log why an ad was shown, how it competed with organic content, and whether the user engaged or hid it.

If ads infrastructure fails, organic feed should continue. If organic ranking fails, do not fill the entire feed with ads. Monetization must degrade behind core user experience.

Likes, comments, shares, hides, reports, impressions, clicks, and dwell time form the feedback loop for ranking. The write path is enormous, so the system records append-only events, computes aggregates asynchronously, and feeds nearline features back to ranking.

Some signals must be fresh. A report or hide should affect future ranking quickly. A viral comment burst may make a post more relevant. Use separate priority lanes: critical safety and negative feedback gets low-latency processing, while bulk counters and offline model training can lag.

Counters should be approximate when needed. Exact global like counts are less important than robust ranking features and low write latency. Use sharded counters, time-windowed aggregates, sketches, and batch compaction to avoid hot rows on viral posts.

Alternative one is a pure chronological pull feed. It is simple and fresh for small products, but it degrades with large graphs, misses relevance, and makes every feed read expensive.

Alternative two is pure push fanout. It gives very fast reads for bounded graphs, but celebrity pages, large groups, and viral producers create enormous write amplification and hot shards.

Alternative three is fully on-demand ML ranking without per-user feed caches. It can be freshest and most personalized, but scoring hundreds of candidates for billions of read requests is usually too expensive and risky for tail latency.

Do not build this full architecture for a small community app, an internal activity stream, or a product where chronological order is the core requirement. Start with a simpler pull model and add caching, fanout, and ranking only when graph size, read traffic, and relevance needs justify the complexity.