Design a Video-streaming frontend

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type PlayerCommand = { type: 'play' | 'pause' } | { type: 'seek'; seconds: number };2type PlayerEvent =3  | { type: 'ready'; duration: number }4  | { type: 'time'; current: number; buffered: number }5  | { type: 'quality'; bitrate: number }6  | { type: 'stalled' } | { type: 'fatal'; code: string };

04Failure-mode analysis

05Observability and operations

• Measure manifest time, time to first frame, rebuffer count/duration, fatal rate, and bitrate switches per device/network cohort.
• Correlate player session id across client events, CDN requests, and progress writes without logging protected media data.
• Sample high-volume time events but send every fatal transition and recovery outcome.
• Canary codec, DRM, and ABR changes behind flags with automatic rollback thresholds.

06Security and accessibility boundaries

• Use signed short-lived media URLs and enforce entitlement on trusted services; hiding controls is not authorization.
• Treat subtitle and metadata payloads as untrusted and parse without HTML injection.
• Provide keyboard-operable controls, visible focus, captions, audio-track selection, and non-color state indicators.
• Honor reduced motion and never let autoplay with sound bypass user-agent policy or user preference.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

This answer goes wrong when you open with 'I'd use HLS'. Do it in order: pin down what kind of video and what 'good' means, draw a small number of boxes, then spend most of the time on the one genuinely hard part — keeping playback smooth when the network wobbles — and only then talk about failure and scale. Here is that walk, in the words you would actually use.

1. Step 1 · Clarify what you are building

   Say: 'Before I design anything, a few questions. Is this video-on-demand, live, or both? Roughly how many concurrent viewers at peak? Which devices — just web, or also mobile and TV? And what is the bar for good: startup time, how often it is allowed to buffer?' Then state your assumptions so they can correct you: 'I will assume on-demand first, about 100,000 concurrent viewers at peak, web and mobile, startup under two seconds, buffering under one percent of watch time.' Two minutes here stops you designing the wrong thing.

2. Step 2 · Turn that into requirements

   Split into what the user sees and what shapes the design underneath. User-facing: play, pause, seek, choose quality, pick captions and audio track, and resume where you left off on any device. Underneath: adaptive quality so it does not buffer, recover from a failed chunk without a hard error, and never let the recommendations rail or analytics slow the player. Write these where the interviewer can see them.

3. Step 3 · Draw the boxes, keep it small

   Four boxes. One: a player core that wraps the messy parts — the streaming format like HLS or DASH, the browser Media Source API, DRM, device quirks — behind a clean 'commands in, events out' interface. Two: a thin UI shell (controls, overlays, recommendations) that only reacts to the player's state events and never touches the video element directly. Three: a CDN that serves every video byte. Four: a small watch-progress service the client checkpoints to periodically. Say why the core is isolated: 'so device and format complexity live in one place, and I can swap the playback engine without rewriting the controls.'

4. Step 4 · Deep-dive: adaptive bitrate, the actual hard part

   Spend the most time here. 'The client fetches a manifest that lists the video at several quality levels, each cut into short segments. Before each segment, an algorithm on the client picks a quality from two signals: how fast recent downloads have been, and how much buffer is left. If the buffer is draining it steps down; if it is healthy and the network looks good it steps up — but conservatively, because viewers hate quality that flip-flops every few seconds more than they mind a slightly lower resolution.'

5. Step 5 · Failure: a segment does not load

   'If a segment request fails I do not show an error straight away. I retry with a little random delay, and if it keeps failing I try a different CDN or drop to a lower quality that might arrive in time — all while keeping the current playback position. Only after a bounded number of failed recovery attempts do I show a real error. And progress writes never block playback: if that service is down I keep the latest position locally and retry later.'

6. Step 6 · Scale and the main-thread trap

   'The scaling insight is that the video bytes go to the CDN, not my servers — my application servers only handle manifests, entitlement, metadata, and progress, which is a tiny fraction of the bytes. The other thing I watch is the main thread: if the UI does heavy work the controls and captions lag even when the video buffer is fine, so I keep the player's event handling lightweight and defer the recommendations and analytics.'

7. Step 7 · Name what you would measure

   'I would track time to first frame, how often and how long it rebuffers, the fatal-error rate, and the number of quality switches — all split by device and network type, because a problem on slow mobile hides in an average. Every fatal error and recovery is logged; the routine time-update events are sampled.'

QAInterview questions and model answers