How the interviewer opens it
“Design live comments for posts and live videos, like Facebook. New comments should appear quickly for people watching, including on videos with millions of viewers.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Product scope
- Scale
- Read:write mix
- What every viewer must receive
- Latency
- Consistency and durability
- Ordering and retries
- Reconnect behavior
- Payload and retention
- Geography
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Submit and durably acknowledge a text comment on a post or live video
- Read paginated comment history
- Deliver a live comment stream to connected viewers within two seconds
- Reconnect without silently losing the viewer's place
Usually out of scope
- Video streaming itself
- Threaded replies, reactions, and attachments
- Building authentication or a moderation classifier
- Notifications to people who are not watching
- Search across comments
What interviewers probe
- Fanout to millions without treating viewers as broker consumers
- One hot parent has modest write ingress but enormous outbound multiplication. Adding write partitions does not reduce the bytes that must reach viewers, and a single broker or gateway can become the bottleneck.
- Durable acceptance, retry safety, and per-parent order
- The API acknowledgment, durable history, and live stream are different stages. A crash between stages can lose a supposedly accepted comment, publish a comment that never becomes durable, or create duplicates and conflicting order.
- Joining, reconnecting, and slow viewers
- The history API and live stream overlap but are not identical: the live stream may omit accepted comments. Reconnect storms and slow clients can turn a bounded shared stream into unbounded per-viewer work unless cursors and gap semantics are explicit.
Common mistakes
- Designing only comment CRUD and adding 'WebSockets' as an unexplained delivery box.
- Sizing the system from comment writes while ignoring viewers multiplied by comments and payload size.
- Quietly sampling comments without clarifying whether the product permits it, or promising every comment despite the stated live-display cap.
- Using a consumer-group model that load-balances events among viewers rather than broadcasting them.
- Treating database writes and live publication as an atomic operation when they are not.
- Ignoring the history-to-live boundary, reconnect storms, and bounded queues for slow clients.
The bar by level
- Senior (L5/E5)
- Quantifies hot-video egress, clarifies bounded live semantics, and designs shared selection plus relay/gateway fanout. Gives a sound durability and idempotency story, stable per-parent ordering, coordinated history/live boundaries, bounded replay, and explicit slow-client behavior. Chooses partitioning based on the hot parent's write rate rather than its audience alone.
- Staff (L6+/E6+)
- Separates ordering authority, selection, and delivery into independently scalable responsibilities while keeping the common path simple. Handles ownership fencing, selector failover, regional fanout, and mass reconnect recovery with explicit capacity limits. Distinguishes normal-operation latency from failure guarantees, explains the unavoidable cost of full fanout or personalization, and states where the system rejects writes, resets viewers, or relaxes availability.