Design a Twitter / X News Feed

The news feed question is a proxy for one real question: do you understand write amplification?Any system that must broadcast one event to many recipients has to decide whether to do work at write time or at read time. The tradeoffs are not obvious, and they change depending on the data distribution — specifically, whether users follow power-law distributions (a handful of accounts with tens of millions of followers dominating the write path).

Three secondary signals matter here. A naive design — query the database on every feed load — simply does not work at this scale; the numbers make that obvious before any architecture is drawn. Cache consistency is non-trivial in a system with two independent write paths (fan-out writes timeline IDs, engagement writes update tweet objects); recognising that the two caches must be invalidated separately is a design smell test. And at L5+, ranking is the difference between a feed that feels alive and one that feels like a log dump — the system must be built to support re-scoring even if the initial design is chronological.

Before drawing a single box, pin down scope. A news feed interview can go many directions — live sports scores, Instagram-style media, LinkedIn professional posts — and each changes the design materially.

Functional requirements

Non-functional requirements

Twitter-scale systems are write-amplified: one tweet may need to be placed into millions of follower timelines. The defaults below reflect a large-scale Twitter-like platform — 100M tweets per day, 200M active users — roughly comparable to Twitter's 2019–2020 scale. Adjust the sliders to match the scale you' re discussing in your interview.

Four dimensions matter here. Traffic dominates the cache sizing and fan-out throughput. Storage is driven by tweet retention and media references. The read:write ratio determines how heavily the cache must absorb reads relative to writes — on social platforms this is typically 30–100×. The critical output is fan-out QPS — the rate at which timeline entries are written when tweets arrive.

Component breakdown

Load Balancerroutes traffic to write and read API clusters separately. This allows independent scaling: write capacity scales with tweet volume, read capacity with user sessions.

Write APIvalidates the tweet (content, media references, rate limits), writes durably to the tweet store, then emits a fan-out event to a durable message queue (Kafka). The response returns to the client after the durable write — not after fan-out completes. Media is uploaded separately via a pre-signed object store URL (e.g. Amazon S3) before the tweet is posted; the media_idsfield carries references to already-uploaded objects, served to end users through a globally distributed CDN.

Tweet Storeis a wide-column database (Apache Cassandra) keyed on user_id+tweet_id. This access pattern — "give me all tweets by user X" — maps naturally onto Cassandra's partition model. Cassandra' s multi-datacenter replication satisfies the 8-nine durability NFR from §2.

Message Queue (Kafka)buffers tweet events between the write API and fan-out consumers. It absorbs bursty celebrity-tweet spikes, ensures at-least-once delivery to fan-out workers, and provides a replay mechanism for consumer failures.

Fan-out Serviceconsumes from Kafka, looks up the tweeter's follower list in the user graph, and writes a tweet ID reference into each follower' s pre-computed timeline in the timeline cache. Normal users trigger push fan-out; celebrities (above a follower threshold) are skipped and handled at read time (§5).

User Graphstores follow relationships. Reads are extremely hot — every fan-out needs the full follower list for a user. A graph database (or a custom adjacency-list service like Twitter's FlockDB) is optimised for this traversal. The follower list for an active user is cached in memory.

Timeline Cache (Redis) stores pre-computed home timelines as sorted lists of tweet IDs per user. Each list holds ~800 recent tweet IDs (not full objects). Reads hit this cache first; a cache miss triggers a slower rebuild from the tweet store.

Hydration Cache (Redis) stores full tweet objects, keyed by tweet ID. When the read API fetches tweet IDs from the timeline cache, it hydrates them in a parallel batch from this cache, falling back to the tweet store. This separates "what is in your feed" from "what does each tweet contain," allowing engagement counts to update without invalidating timelines.

Notification Gateway handles real-time delivery to connected clients via a persistent connection protocol (WebSocket or Server-Sent Events). When the fan-out service writes to a follower's timeline cache, it also publishes to a per-user notification topic; the gateway pushes this signal to any active client connection. Mobile clients without an active connection receive a platform push notification — APNs for iOS, FCM for Android — which wakes the app to fetch the delta from the feed service.

Architectural rationale

Real-world comparison

Fan-out is the central algorithm of a news feed: when a tweet is published, which followers see it and when? There are two extremes and a hybrid that nearly every production social platform converges on.

Our choice for this system is the hybrid. The 200 ms latency NFR from §2 rules out pure pull (assembling feeds from 1, 000 followees at read time cannot reliably hit 200 ms p99). The fan-out write capacity NFR rules out pure push for accounts with millions of followers. The hybrid threads both constraints.

Two core endpoints drive the system. Both carry implicit authentication via a JWT or session token validated at the API gateway layer before reaching these services.

POST /tweets — Create a tweet

 // Request
                POST /v1/tweets Authorization: Bearer < token>

                Content-Type: application/json {
                    "text" : "Hello world — 280 chars max" ,
                    "media_ids" : ["m_abc123" ],  // pre-uploaded media references
                    "reply_to_tweet_id" : null,  // null if top-level tweet
                    "idempotency_key" : "uuid-v4"   // client-generated; prevents duplicate posts
                }

                 // Response — 201 Created

                    {
                    "tweet_id" : "1843927401234567168" ,
                    "created_at" : "2026-03-29T10:00:00Z" ,
                    "author_id" : "u_42" ,
                    "fan_out_status" : "queued"   // fan-out is async; not yet delivered
                }

                

Validation rules: text must be 1–280 characters; media_ids must reference pre-uploaded objects (not inline uploads); idempotency_key deduplication window is 24 hours. Rate limiting is enforced at the API gateway: 300 tweets per 3-hour rolling window per user, counted via a sliding window counter in Redis.

GET /feed — Home timeline

 // Request
                GET /v1/feed?limit=20& cursor=eyJsYXN0X3R3ZWV0X2lkIjoiMTg0MDAwIn0 Authorization: Bearer < token>

                 // Response — 200 OK

                    {
                    "tweets" : [ {

                        "tweet_id" : "1843927401234567168" ,
                        "text" : "Hello world" ,
                        "author" : {
                            "user_id" : "u_42" , "handle" : "@alice" 
                        }

                        ,
                        "created_at" : "2026-03-29T10:00:00Z" ,
                        "engagement" : {
                            "likes" : 128, "retweets" : 34
                        }

                        ,
                        "media" : []
                    }

                     // ... up to limit items
                    ],
                    "next_cursor" : "eyJsYXN0X3R3ZWV0X2lkIjoiMTgzOTAwIn0" ,
                    "has_more" : true
                }

                

Cursor-based pagination (not offset) is mandatory here — offset pagination would require counting rows from the beginning of the timeline on every page, which is expensive on distributed caches. The cursor encodes the last seen tweet_id; the feed service continues from that point.

The latency NFR from §2 (200 ms p99) is determined almost entirely by the read path — specifically by the two sequential cache lookups (timeline IDs, then tweet objects). The write path is comparatively relaxed; a 500 ms write is acceptable. The read path is where the architecture either succeeds or fails at scale.

The key tradeoff in this flow is the cache-miss path. A cold cache (user hasn't loaded their feed in days) requires querying the tweet store for each followee' s recent tweets, merging and sorting them, then populating the cache — potentially 200–500 ms. To hit 200 ms p99, the cache-miss path must rarely execute; at a target p99, a 2% miss rate means 1-in-50 requests lands on the slow path, which is tolerable if each miss takes under 400 ms. This is why timelines are preheated for active users in the background (§8) rather than rebuilt lazily on first request.

There are four core entities: User, Tweet, Follow, and Timeline. Each is accessed very differently, which ends up shaping the storage choice per entity.

Access patterns

Two patterns stand out from this table. First, timeline ID lookups and tweet hydration dominate by volume — both are point lookups, which maps cleanly onto caches (Redis) and key-value stores. Second, follower scans are write-path-critical but read infrequently relative to timeline reads — this justifies a specialised graph store rather than a general-purpose database.

Schema

The 200 ms p99 latency NFR from §2 is only achievable because multiple cache layers eliminate database round trips on the hot path. Each cache layer has a specific role in the §4 architecture.

A single-region, single-instance version of this system breaks in at least five ways as load grows. The following topics each address one of those breakage modes — they are independent of each other and can be drilled into in any order.

Classic interview probes