Design the playback path for a global video streaming service. What are the architecturally significant decisions?

What the interviewer is testing

Whether you can identify the decisions that matter rather than drawing every component.

The decisive insight

Video bytes and control decisions have completely different architectures, and separating them is the whole design.

The control plane — authentication, entitlement, catalogue, personalisation, playback authorisation — is small, dynamic, personalised and latency-sensitive in the hundreds of milliseconds. It runs in cloud regions.

The data plane — the video segments themselves — is enormous, static, identical for every viewer of a title, and bandwidth-dominated. It must be served from as close to the viewer as possible.

Conflating them produces a design that either serves video from regions (ruinous in bandwidth cost and latency) or tries to personalise at the edge (unnecessary complexity).

The playback sequence

The client authenticates and requests playback. The control plane authorises, selects the appropriate encodings, and returns a manifest listing segment URLs plus a set of candidate delivery locations. The client then fetches segments directly from the nearest healthy location, adapting bitrate to measured throughput.

Note what this achieves: the control plane is consulted once per playback, not per segment, so its load is proportional to sessions rather than to bytes.

The decisions worth naming

Content is pre-positioned, not pulled on demand. Popular titles are pushed to edge locations ahead of viewing, because a cache miss on a large video segment is expensive and predictable demand makes prediction easy.

Adaptive bitrate with client-side selection, because only the client knows its actual throughput, and shifting that decision to the client removes a per-segment server interaction.

Multiple encodings per title, trading storage — which is cheap — for delivery efficiency and device compatibility, which are not.

Graceful degradation in the control plane: personalisation failing must not prevent playback. Playback is the product; recommendations are an enhancement.

What a strong answer adds

Placing servers inside ISP networks rather than only in cloud regions, which is what Netflix's Open Connect does. The economics are decisive at this scale: delivering from within the ISP's own network removes transit cost for both parties and shortens the path, which is why ISPs accept the appliances.

And the cost framing: at streaming volume, bandwidth dominates the architecture the way latency dominates a trading system. The design follows from which resource is scarce.

Common weak answers

A generic CDN in front of an origin, without separating control and data planes. Designing the recommendation system, which was not asked for and is not the playback path.