System Design: How to Design a Social Media Feed

The social feed is the classic "hard" design question — it looks simple until the interviewer asks what happens when a celebrity with 100M followers posts. This walkthrough covers the core trade-off (fan-out on write vs on read), feed ranking, and media handling, all with the 4-step framework.

Step 1 — Requirements

Functional: users post content (text + images/video); users follow other users; the home feed shows recent posts from followed accounts, newest first (start here — add ranking only if asked). Non-functional: feed loads fast (users bounce after ~2 seconds); massive read scale; posting can tolerate slight delay — nobody notices if a post appears 5 seconds late.

Scope question to ask: "Should I include stories, DMs, and the explore page, or focus on the core post/follow/feed loop?" (Focus on the loop.)

Step 2 — Estimation

• 500M daily active users; average user follows 200 accounts.
• 100M new posts per day → ~1,200 writes/sec average.
• Feed reads: 500M users × 2 feed opens/day = 1B reads/day → ~12,000 reads/sec average, 3x at peak ≈ 35,000/sec.
• Read:write ratio ≈ 30:1. Like the URL shortener, this is a read-heavy system — but with a twist (below).
• Media storage: 100M posts/day × 2 MB average media ≈ 200 TB/day → object storage (S3-style), never the database.

Step 3 — High-level design and API

POST /api/posts        { "userId": "...", "text": "...", "mediaIds": [...] }
POST /api/follow       { "followerId": "...", "followeeId": "..." }
GET  /api/feed?cursor=...&limit=20   -> ranked list of posts

Boxes and arrows: client → load balancer → app servers → (a) post/metadata DB, (b) graph DB or follow table, (c) object storage for media, (d) cache in front of feeds, (e) CDN for media delivery. Media uploads go direct to object storage; only metadata touches the app servers.

Step 4 — Deep dive 1: fan-out on write vs fan-out on read

This is the heart of the question. When user X posts, how does it reach followers' feeds?

• Fan-out on write (push): on post, insert the post ID into a feed cache entry for every follower. Reads are then a single cache lookup — blazing fast. Cost: a celebrity with 100M followers triggers 100M writes for one post, and inactive followers' feeds get computed for nothing.
• Fan-out on read (pull): on feed load, fetch recent posts from everyone the user follows and merge. Cheap writes, but reads fan out to hundreds of accounts — slow and spiky.

Recommended answer: "Hybrid — the industry standard. Fan-out on write for normal users (fast reads, the common case); fan-out on read for celebrities above a follower threshold (avoids the 100M-write thundering herd). Instagram and Twitter both do variants of this." Name the celebrity problem explicitly — interviewers are waiting for it.

Deep dive 2 — Feed storage, ranking, and caching

• Storage: a per-user feed cache (Redis sorted set, scored by timestamp) holds post IDs; post content lives in the metadata DB / object store. The feed is an index, not the data.
• Pagination: cursor-based (?cursor=<last_post_id>), never OFFSET — offsets break as new posts arrive and get slow at depth.
• Ranking (if asked): score = recency × affinity (past interaction with the author) × content quality signals. Keep it to one paragraph unless they dig — ranking is its own interview.
• Caching: precomputed feeds in Redis with TTL; cache-aside on miss. Hot users' feeds stay warm permanently.

Deep dive 3 — Media pipeline

Upload → object storage → async processing queue (thumbnails, multiple resolutions, compression) → CDN URLs stored with the post metadata. The post itself is visible immediately with a "processing" placeholder for video. Never block the post request on media transcoding — that's the async-processing principle from the primer.

Follow-ups interviewers love (and one-line answers)

• "A celebrity posts during the Super Bowl — what breaks?" — The fan-out write storm; answer: celebrity accounts use fan-out on read, plus queue the push with backpressure.
• "How do you keep the feed under 2 seconds at 35k reads/sec?" — Precomputed per-user feeds in cache; reads never touch the database on the hot path.
• "Consistency — can a follower miss a post?" — Eventual consistency is fine here; a post appearing seconds late is invisible to users. State it confidently.
• "How would you add 'stories'?" — Same pipeline, but TTL-based expiry (24h) and a separate lightweight feed — shows you can extend a design.

In this series

1. System Design Interviews: A Practical Primer — the 4-step framework.
2. System Design: URL Shortener and Rate Limiter, End to End — the classic warm-up questions.
3. System Design: How to Design a Social Media Feed (this post) — fan-out, ranking, and the celebrity problem.