Design a Live Comments Feature for Facebook — System Design Interview Practice

Interview prompt

Design Facebook-style live comments with threaded replies, pagination, moderation, reactions, and near-real-time updates for ordinary and viral posts.

• Keep the comment record and moderation state authoritative while treating room membership, unread counts, and fanout as projections.
• Use cursor pagination and per-post partitions, with coalesced deltas and fanout limits protecting viral rooms.
• Make posting and moderation idempotent, preserve parent relationships, and recheck visibility when serving stale projections.
• Explain ordering, reconnect cursors, deleted parents, blocked users, abuse rate limits, and slow-client backpressure.

Requirements and scale assumptions

• Create, edit, delete, reply to, react to, report, and paginate comments under a post.
• Subscribe to a post room, receive ordered deltas, reconnect from a cursor, and fall back to polling when live delivery fails.
• Support moderation quarantine, blocked users, privacy, anti-spam limits, notification preferences, and audit history.
• Target p95 comment acknowledgement below 200 ms and deliver live deltas below 2 seconds for healthy rooms.
• Handle 20 million comments per day and viral posts with millions of viewers without synchronous per-viewer writes.
• Make comment commands and fanout events idempotent; preserve a durable sequence per post for reconnects.
• Coalesce or shed low-priority deltas for slow clients while retaining durable comments and moderation actions.
• Support 20 million comments per day, 5 million concurrent room subscribers, and highly skewed viral posts.
• Partition by post ID and shard hot rooms; isolate moderation queues and notification fanout from comment writes.
• Retain comment sequences, tombstones, moderation evidence, and event offsets while bounding room presence state.

• Peak scale: Support millions of comments per day — Capacity assumption that drives partitioning and backpressure.
• Latency target: Real-time updates for new comments — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The source of truth is Post and view comments in real-time; Support nested/threaded comments.
• Async boundary: At-least-once workers — Keep WebSockets for real-time updates, Message queue for comment processing, Nested set model for threaded comments off the synchronous path.

Key entities

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

  Canonical live comments feature interaction with an idempotency key and ordering version.

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

  Ephemeral but observable live comments feature connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for live comments feature fan-out and replay.

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

  Deduplicated live comments feature delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe live comments feature 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 live comments feature transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route live comments feature 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 live comments feature service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks live comments feature 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 live comments feature 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 live comments feature 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 live comments feature 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 live comments feature 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.