Requirements & scope
Problem Statement & Requirements
Functional Requirements
- Publish posts -- users create text posts, links, photos, or videos
- News feed -- a personalized, ranked stream of posts from friends/followed accounts
- Retweet / share -- amplify someone else's post to your followers
- Like, reply, quote-tweet -- engagement actions
- Follow / friend -- asymmetric (Twitter: follow) or symmetric (Facebook: friend)
- Trending topics -- surface popular topics in real-time
- Notifications -- new followers, likes, mentions, replies
- Real-time updates -- new posts appear in feed without manual refresh (for active users)
Non-Functional Requirements
- Low latency -- feed renders in < 500 ms
- High availability -- 99.99% uptime
- Eventually consistent -- slight delay in feed propagation is acceptable
- Massively read-heavy -- read:write ratio ~1000:1
- Scalability -- 500M+ DAU, 1B+ feed reads/day
- Freshness -- breaking news and viral content surface within seconds
Key Differences from Instagram Design
| Aspect | Twitter / Facebook | |
|---|---|---|
| Primary content | Photos/video | Text + mixed media |
| Feed model | Visual grid + ranked feed | Chronological stream (Twitter) or ranked (Facebook) |
| Engagement style | Like + comment | Like, reply, retweet, quote-tweet, bookmark |
| Amplification | None (no reshare) | Retweet = core mechanic, viral amplification |
| Graph type | Asymmetric (follow) | Twitter: asymmetric; Facebook: symmetric |
| Real-time need | Moderate | High (breaking news, live events) |
| Threading | Flat comments | Threaded conversations (Twitter threads) |
Scale estimations
Scale Estimations
Users & Content
| Metric | Value |
|---|---|
| Daily Active Users (DAU) | 500M |
| Total users | 2B |
| New posts / day | 500M |
| Average post size (text + metadata) | 1 KB |
| Posts with media | 30% (images/video served via CDN) |
| Average friends/following per user | 300 |
| Avg feed reads per user per day | 10 |
| Total feed reads / day | 5B |
Traffic
| Metric | Value |
|---|---|
| Feed reads / second (avg) | ~58K RPS |
| Feed reads / second (peak) | ~200K RPS |
| Post writes / second | ~5,800 WPS |
| Read:Write ratio | ~10:1 (feed reads) to ~1000:1 (including passive reads) |
Storage
| Metric | Value |
|---|---|
| Post storage / day | 500M x 1 KB = 500 GB/day |
| Post storage / year | ~180 TB/year |
| Feed cache (Redis) | 500M users x 500 post_ids x 16 bytes = ~4 TB |
| Social graph | 2B users x 300 avg edges = 600B edges |
Fanout
| Metric | Value |
|---|---|
| Avg followers per poster | 300 |
| Total fanout writes / day | 500M posts x 300 = 150B feed cache writes/day |
| Fanout writes / second | ~1.7M WPS |
| Celebrity post (10M followers) | 10M writes per single tweet |
Layered architecture
Phase 1 of 4 · Client & edge
Start with the entry points
First, define who uses the system and where requests enter. This is the boundary of the design, not yet a complete request path.
- Client
- Separate the publish path from the latency-sensitive timeline read path.
- API gateway
- Authenticate requests and protect expensive feed generation from abusive traffic.
This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.
API & contracts
Phase 2 of 4 · Application & compute
Add the application logic
Keep the entry points and add the services that do the work. Give each service a clear responsibility before defining its contracts. Storage and background dependencies come next.
- Post service
- Commit post content and metadata before asynchronous distribution begins.
- Fanout service
- Push regular users' posts to followers, but merge high-fanout accounts on read.
- Feed + ranking
- Gather candidates, apply visibility filters, then score and order the timeline.
A feed response needs stable item IDs and an opaque cursor, not just a page number. Carry the ranking or snapshot context needed to continue a reading session. Post creation should have its own idempotency boundary, and every feed read must apply current visibility rules even when candidate IDs came from an older cache.
Data model
Phase 3 of 4 · Data & async work
Connect data and background work
The services now need their dependencies: durable state, fast lookups, or work that continues outside a request. Separate these responsibilities rather than treating every component as a database.
- Post store
- Persist posts independently of any derived feed cache so feeds can be rebuilt.
- Feed cache
- Store compact ordered IDs and fetch post objects in batches.
- Graph + features
- Use graph relationships for candidates and freshness-aware features for ranking.
Data Model
Posts Table
Conversation Threading
Core design decisions
Ranking System (Deep Dive)
Feature Categories
Ranking Model Architecture
Two-Phase Ranking
Fanout Strategies Compared
Request flows
Post Publishing Flow
Retweet / Share Flow
Feed Read Flow -- Timeline Assembly
This is the core of the design -- how a user's feed is constructed on read.
Timeline Assembly Flow Diagram
Performance & caching
Caching Architecture (Multi-Layer)
Advanced design
Real-Time Feed Updates
Trending Topics
Handling Viral Posts
Edge cases
A reader may refresh while new posts arrive and older posts are deleted. Define whether the cursor represents a snapshot or a moving window, then avoid duplicating items within that contract. Blocks and privacy changes override cached membership: appearing in a precomputed feed is not sufficient authorization to display a post.
Tradeoffs
Tradeoffs & Design Decisions Summary
| Decision | Option A | Option B | Chosen | Why |
|---|---|---|---|---|
| Fanout strategy | Fanout-on-write | Fanout-on-read | Hybrid | Push for normal users (fast reads), pull for celebrities (avoid 100M writes) |
| Feed order | Chronological only | ML-ranked only | Both tabs | "Following" for chronological purists; "For You" for engagement optimization |
| Ranking model | Single-task (P(click)) | Multi-task (like, reply, RT, hide) | Multi-task | Optimizes for healthy engagement, not just clicks |
| Ranking pipeline | Single model | Two-phase (pre-rank + heavy rank) | Two-phase | Pre-rank prunes 80% cheaply; heavy rank uses expensive features on fewer candidates |
| Real-time updates | WebSocket (all users) | Polling + SSE hybrid | Hybrid | Only ~5% of users are actively watching feed; WebSocket for all is wasteful |
| Feed cache | Database query | Redis sorted set | Redis | O(1) reads, pre-computed, handles 200K RPS |
| Post cache | Redis | Memcached | Memcached | Simple key-value, no persistence needed, better memory efficiency for cache |
| Trending detection | Batch (hourly) | Stream processing (real-time) | Stream (Flink) | Trends need to surface within minutes, not hours |
| Trending metric | Absolute volume | Relative spike vs baseline | Relative spike | "Weather" always has high volume but isn't trending; relative detects actual spikes |
| Retweet storage | Copy post | Pointer to original | Pointer | One post can have 1M retweets -- can't copy 1M times |
| Thread model | Flat replies | Conversation threading | Threading | conversation_id groups all replies; reply_to enables tree structure |
| Out-of-network content | None (only followed users) | SimClusters + social proof | SimClusters | "For You" tab needs content discovery beyond your follows |
| Viral post handling | Same as normal | Hot key replication + async counters | Special handling | 100K reads/sec on one post breaks a single cache node |
| Counter updates | Synchronous DB write | Kafka -> aggregate -> batch flush | Async batch | Can't do 100K writes/sec to a single row |
Reliability & fault tolerance
Phase 4 of 4 · Operations & resilience
Add operational safeguards
With the request paths and tradeoffs established, add the controls that help detect trouble and keep the system operating. The final diagram retains every layer introduced so far.
- Event pipeline
- Track fanout lag and cap expensive viral workloads before queues cascade.
If personalized ranking fails, a chronological list of permitted recent posts is often more useful than a blank page. Bound how long feed assembly waits for optional signals. Keep post records authoritative and rebuild derived feed entries from durable events when fanout workers fall behind.
Production architecture
High-Level Architecture
Detailed Architecture
Production Architecture
Further exploration
Twitter-Specific: "For You" vs "Following"
Interview playbook
Interview Tips
Frame the two core problems -- "A news feed has two hard problems: (1) how to build the feed efficiently (fanout strategy) and (2) how to rank it (ML pipeline). Let me address both."
Fanout is the opening move -- Start with fanout-on-write vs fanout-on-read. Show the celebrity problem. Land on hybrid. This is the foundation everything else builds on.
Timeline assembly is the full picture -- "Building the feed is a 5-stage pipeline: gather candidates, hydrate, rank, filter, return." Walk through each stage. This shows you think about the complete system, not just storage.
Ranking shows ML maturity -- "We use a multi-task model that predicts P(like), P(reply), P(retweet), and P(hide). The final score is a weighted combination optimizing for healthy engagement." Name specific features.
Caching layers show systems depth -- "There are 6 layers of cache: client SQLite, CDN for media, Redis for feed, Memcached for posts, Memcached for users, TAO for social graph." Name each one and its purpose.
Trending is a stream processing problem -- "We use Flink to process every post in real-time, extract entities, count in sliding windows, and compute spike ratios vs baseline." Shows you know stream processing.
Retweet is a unique design concern -- "A retweet is a pointer, not a copy. It triggers the same fanout as a new post but for the retweeter's followers. Celebrity retweets = same celebrity fanout problem."
Real-time updates are overvalued -- "Only ~5% of users are actively watching their feed. For the other 95%, the feed is assembled on next app open. Don't over-engineer WebSocket for everyone."
"For You" vs "Following" is a product decision -- "Algorithmic feeds increase engagement 40-60% but users feel less control. Offering both tabs is the modern compromise."
Viral content handling shows production thinking -- "A single viral post can get 100K reads/sec on one cache key. We detect hot keys, replicate across cache shards, and use approximate counters to avoid write storms."