Skip to content

03. Live Streaming Platform — Interview Q&A

~15 min read · Part 4 of 4 (Overview → HLD → LLD → Q&A)

Q1. How is live streaming different from video-on-demand? The content doesn't exist until it's streamed, so you can't pre-encode or pre-warm anything. Transcoding runs in real time, segments are produced ~2s before viewers request them, and the manifest is a rolling window of recent segments. Live optimizes latency (glass-to-glass in seconds) whereas VOD optimizes throughput and can pre-position everything. Common wrong answer to avoid: "Same as VOD but the file grows." Missing the real-time constraint — you're racing the encoder against viewers' buffers, with no ability to pre-warm.

Q2. 5 million viewers on one stream — how do you serve 20 Tbps from a single source? Same CDN fan-out as VOD: live segments are immutable once produced and identical for all viewers, so they cache at the edge. The difference is you warm the edge segment-by-segment as each is produced, rather than pre-positioning. The 20 Tbps spreads across thousands of edges; origin serves one fill per segment per edge. Common wrong answer to avoid: "Stream directly from the origin to each viewer." One source can't fan out to 5M; the CDN and immutable segments are mandatory.

Q3. What sets the latency floor, and how would you get sub-second latency? With chunked HLS, latency ≈ segment duration + player buffer, so ~2–6 seconds; shrinking segments lowers it but raises overhead. For sub-second interactive latency you switch transport to WebRTC via an SFU fleet, which trades CDN cacheability (and cost efficiency) for real-time delivery. Pick HLS for large passive audiences, WebRTC for small interactive ones. Common wrong answer to avoid: "Just use smaller segments to get to milliseconds." Chunked HLS has a floor set by buffering; true sub-second needs a different transport (WebRTC), not just tuning.

Q4. During a clutch moment, chat hits 50k messages/second with 5M viewers. How? You don't deliver 50k/s to all 5M — that's 250 billion deliveries/second and no human could read it. Chat reduces fan-out: per-user rate limits (slow mode) cut the input, room sharding spreads connections across gateway nodes with pub/sub broadcast, and on huge channels the displayed scroll is sampled/batched so each viewer sees a legible subset. Common wrong answer to avoid: "Broadcast every message to every viewer." Physically impossible at that scale and useless — nobody reads 50k messages/second.

Q5. What happens if the transcoder can't keep up with real time? Latency grows and, unlike VOD, never recovers within the stream — you're permanently behind. Mitigations: provision headroom, and under pressure shed the highest rendition (or briefly lengthen segments) to regain real-time rather than letting the live edge drift. Falling behind is the defining live failure. Common wrong answer to avoid: "Buffer more and catch up later." There's no 'later' in live; you must stay real-time by shedding work, not by buffering.

Q6. How do you count concurrent viewers when millions join at once? Approximately, with a HyperLogLog (or sampled counter): O(1) inserts, kilobytes of memory, ~2% error. An exact per-join counter would be a crushing hot write at stream start, and "5.0M vs 5.02M" is a display detail, not a decision. Approximate is the correct tradeoff. Common wrong answer to avoid: "Increment an exact counter on every join." A hot counter can't absorb millions of simultaneous joins and buys precision nobody needs.

Q7. How does the same system produce a replay (VOD) after the stream ends? Live segments are retained as they're produced; when the stream goes offline, they're sealed into a complete manifest and served by the standard VOD/OTT path. DVR (seeking back during the live stream) reads those same retained segments. Live and VOD share storage; only the manifest (rolling vs complete) differs. Common wrong answer to avoid: "Re-record and re-transcode for VOD." The segments already exist; you just assemble a complete manifest from them.

Q8. A viewer's buffer stalls and they fall behind the live window. What happens? The rolling manifest only lists recent segments, so a segment that's aged out no longer exists at the edge. The player can't request an evicted segment, so it re-joins at the current live sequence (a small jump forward). This is the cost of the sliding window that keeps live storage bounded. Common wrong answer to avoid: "Keep all segments so they can catch up." That's VOD; live keeps a bounded window and viewers who fall off re-join at the edge.

Q9. How do you keep chat message order sane across sharded gateways? Messages flow through the room pub/sub with a message id/timestamp; gateways deliver in received order and dedup by id. Chat order is best-effort (a few messages reordering by milliseconds is invisible in a fast scroll), so you don't need a global total order — just per-room broadcast with dedup. Common wrong answer to avoid: "Enforce a global total order on chat." Unnecessary and unscalable; chat tolerates approximate ordering.

Deeper follow-ups

  • How would you support co-streaming (multiple broadcasters in one stream)?
  • How would you add real-time moderation to chat without adding latency?
  • How would you handle regional edge failures mid-stream for a global audience?
  • How would you offer both a low-latency (WebRTC) and a scale (HLS) tier of the same stream?
  • How would you detect and mitigate stream sniping / re-streaming abuse?
  • How would you bill/meter egress fairly across broadcasters?

How this round is scored

The live round tests whether you see what makes live not VOD: the inability to pre-encode or pre-warm, and the encoder racing viewers' buffers in real time. The senior signal is treating video and chat as two separate fan-out problems, naming the HLS-vs-WebRTC latency fork with a reason, and — the sharpest point — recognizing that chat at 50k/s to 5M viewers must be reduced (rate-limit, sample, shard), not brute-forced, because delivering everything is both impossible and pointless. Approximate viewer counting and the rolling-window manifest show you understand where exactness is worth sacrificing. Weak answers describe VOD with a growing file; strong ones center latency and fan-out reduction.