Design Twitter for millions of users — System Design Interview Practice

Interview prompt

Design Twitter for millions of users: people can publish short posts, follow accounts, read a home timeline, and see new posts appear without overwhelming the system when popular users publish.

• Separate the durable post and follow graph from the read-optimized home timeline projection.
• Choose a fanout strategy based on follower count and make celebrity posts safe for hot keys and burst traffic.
• Define cursor pagination, ordering, deletion, privacy, and idempotency instead of treating the feed as an unbounded list.
• Keep media processing, search, analytics, and notifications asynchronous so timeline reads and writes remain predictable.

Requirements and scale assumptions

• Allow authenticated users to publish, delete, and read short text posts with optional media references.
• Allow users to follow and unfollow accounts, then read a reverse-chronological home timeline.
• Show a user's profile timeline and a post detail view with replies, reposts, and likes as extensible interactions.
• Refresh the home timeline and notify clients when new posts are available, subject to visibility and moderation rules.
• Target p95 under 200 ms for a timeline page read and under 150 ms for publishing metadata before asynchronous work.
• A committed post must be durable and eventually visible to eligible followers; brief feed lag is acceptable and observable.
• Support privacy, blocked users, deleted content, abuse controls, rate limits, and authenticated access at every read path.
• Remain available during celebrity-post bursts, regional failures, slow media processing, and partial fanout backlog.
• 500 million registered users, 100 million daily active users, and 50 million posts per day.
• Assume 20 timeline reads per daily active user and 10x traffic bursts around major events.
• Most users follow fewer than 1,000 accounts; a small set of accounts has tens of millions of followers.
• Keep post metadata in a durable partitioned store, media in object storage, and feed entries as rebuildable projections with a retention window.

• Post rate: ~580/s avg — 50M daily posts with burst capacity for live events and retry storms.
• Timeline reads: ~23K/s avg — 100M daily users at 20 reads each; cache and precomputed entries absorb hot reads.
• Read latency: p95 <=200ms — Fetch a bounded page by cursor without scanning the entire follow graph.
• Feed freshness: <=5 seconds — Normal fanout target; show a refresh affordance when stream or projection lag grows.

Key entities

• PostpostId, authorId, text, visibility, createdAt, version, deletedAt

  Immutable post content plus moderation and visibility state.

• FollowEdgefollowerId, followeeId, status, version, createdAt

  Versioned graph edge used for fanout and authorization.

• TimelineEntryviewerId, postId, authorVersion, rank, insertedAt, expiresAt

  Materialized home-timeline item with generation metadata.

• LiveCursoruserId, timelineId, lastEventId, lastVersion, expiresAt

  Reconnect cursor for new-post delivery and resync.

Data flow

1. 1. Publish a postThe post service authenticates the author, validates content and visibility, writes the post and moderation state, and returns the durable version.
2. 2. Update the follow graphFollow edges are conditionally updated and emit graph events that determine future fanout and timeline authorization.
3. 3. Fan out ordinary postsWorkers push post IDs to follower timeline partitions, coalescing retries and isolating authors with large follower counts.
4. 4. Read the home timelineThe timeline service merges pushed entries with pull-time candidates for high-follower authors, ranks them, and returns a cursor.
5. 5. Broadcast and repair live updatesLive gateways send new-post IDs with cursors; clients resync from the timeline when connections or projections fall behind.

Deep dives and trade-offs

• Hybrid fanout for celebrity authorsFor Twitter's post, follow, home-timeline, and live-update platform, post publication is durable before fanout, and every timeline item remains subject to current visibility and graph policy. Design for the failure case where celebrity posts, unfollows, deletes, and reconnect storms must not cause write amplification or stale exposure; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Timeline pagination and rankingFor Twitter's post, follow, home-timeline, and live-update platform, post publication is durable before fanout, and every timeline item remains subject to current visibility and graph policy. Keep this concern off unrelated request paths and partition it by Twitter's post, follow, home-timeline, and live-update platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Deletes, unfollows, and live resyncFor Twitter's post, follow, home-timeline, and live-update platform, post publication is durable before fanout, and every timeline item remains subject to current visibility and graph policy. Keep this concern off unrelated request paths and partition it by Twitter's post, follow, home-timeline, and live-update platform access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Fanout-on-write versus fanout-on-readUse hybrid fanout: push to ordinary followers and pull high-fanout authors at read time. Pure write fanout explodes for celebrities; pure read fanout makes home timelines too slow.
• Precomputed timeline versus ranked queryStore candidate timeline entries and perform bounded ranking/merge on read with cursor state. A fully materialized ranked feed is expensive to invalidate whenever follows or ranking rules change.
• Live push versus reliable pullPush low-latency post IDs with a cursor, but make timeline reads the recovery path. Sockets disconnect; treating push as guaranteed loses posts.