Design Twitter for millions of users — System Design Interview Practice

Interview prompt

Design a microblogging platform for posting short messages, following users, serving personalized timelines, search/trends, notifications, and moderation at massive read scale.

• Define post, follow-graph, visibility, deletion, retweet, and notification semantics with durable idempotent mutations.
• Choose fan-out-on-write, fan-out-on-read, or a hybrid for celebrity accounts; partition hot users and explain timeline freshness and ordering.
• Separate write durability from timeline/index/notification projections and support replay, moderation, and cache invalidation.
• Explain ranking, abuse controls, privacy, regional failure, backpressure, observability, and degraded timeline reads.

Requirements and scale assumptions

• Create, edit where allowed, delete, reply, repost, like, follow/unfollow, and retrieve personalized timelines with pagination.
• Support search/trends, mentions, notifications, privacy/block/mute rules, moderation actions, and media references.
• Make mutations retry-safe, propagate deletion/privacy changes, rebuild timelines, and recover projections after fan-out failure.
• Meet p95 timeline reads under 200ms with a freshness target of 30 seconds for normal posts.
• Scale to 100M daily users, 50M posts/day, and celebrity fan-out without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 100M daily users, 50M posts/day, and 10M timeline reads per second
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 50M posts/day; 10M reads/s — Capacity assumption that drives partitioning and backpressure.
• Latency target: timeline p95 < 200ms; freshness < 30s — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Post and follow records are authoritative; timelines, search indexes, and notifications are derived.
• Async boundary: At-least-once workers — Keep Fan-out service for tweet distribution, Cache timelines and trending topics, Separate read and write paths off the synchronous path.

Key entities

• InteractioninteractionId, actorId, objectId, type, version, occurredAt

  Canonical twitter interaction with an idempotency key and ordering version.

• ConnectionSessionsessionId, userId, deviceId, roomKey, lastHeartbeat, status

  Ephemeral but observable twitter connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for twitter fan-out and replay.

• DeliveryReceiptinteractionId, recipientId, channel, attempt, status, deliveredAt

  Deduplicated twitter delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe twitter gateway authenticates the actor, validates room or object membership, applies rate limits, and conditionally commits the interaction.
2. 2. Publish an ordered eventAn outbox emits the committed twitter transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route twitter events to connected recipients, durable inboxes, or notification channels without making the origin write wait for every recipient.
4. 4. Resume and reconcile connectionsClients reconnect with a cursor; the twitter service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks twitter publish-to-deliver latency, hot partitions, reconnect storms, dropped events, and consumer lag for replay or repair.

Deep dives and trade-offs

• Ordering, idempotency, and hot keysChoose a twitter partition key that preserves required order while distributing high-volume rooms, users, or objects. Use event IDs, inboxes, consumer offsets, and conditional state transitions for at-least-once delivery. Split or isolate hot partitions without changing the client-visible sequence contract.
• Reconnect and replay semanticsIssue resumable twitter cursors with an expiry and a clear snapshot-plus-delta fallback. Bound replay windows and rebuild from durable state when a cursor is too old. Expose version and freshness so a client can distinguish current, catching up, and degraded state.
• Backpressure and presenceKeep connection heartbeats and ephemeral presence separate from durable twitter interactions. Coalesce safe updates, shed low-value work, and protect critical events during reconnect storms. Measure end-to-end delivery, not only broker publish latency.
• Direct fan-out versus pull-based readsUse push for latency-sensitive twitter deltas and pull or replay for reconnect, history, and recovery. A push-only design loses state when clients disconnect and a pull-only design wastes latency and bandwidth.
• Per-recipient queues versus shared streamsUse shared partitioned streams with per-recipient cursors where fan-out is large, and isolate exceptional high-fanout objects. A queue per recipient becomes expensive and hard to inspect at large scale.
• Strong ordering versus availabilityGuarantee ordering only within the scope the product needs, such as a room, object, or conversation. Global ordering introduces a bottleneck and still does not solve duplicate delivery or reconnect recovery.