Design a video streaming platform (YouTube / Netflix)

1. Clarify the requirements

Ask: User-generated uploads (YouTube) or a licensed catalogue (Netflix)? Live streaming in scope? Comments, recommendations, monetisation? Which devices? Global audience?

Functional requirements

• Creators upload videos (up to several GB); they become watchable after processing.
• Viewers stream videos on web, mobile, and TV with quality that adapts to their connection.
• Basic metadata, search by title, and view counts.

Non-functional requirements

• Smooth playback: fast start (around 2 s) and minimal rebuffering.
• Reliable uploads that survive flaky connections.
• Cost efficiency: storage and bandwidth dominate the bill.
• High availability for playback; processing can lag minutes.

2. Estimates

Two conclusions: delivery has to come from a CDN (no origin can serve tens of terabits a second), and storage tiering matters because most videos are rarely watched after their first weeks.

3. High-level architecture

Upload. The client asks the upload service for an upload session, then sends the file in chunks (directly to object storage via pre-signed URLs). If the connection drops, it resumes from the last confirmed chunk. When all chunks arrive, the service records the video as PROCESSING and enqueues a job.

Processing. A job is a small DAG: validate and probe the file, split it at keyframes, encode each chunk into each rendition (for example 240p to 1080p or 4K, in more than one codec), package segments with HLS/DASH manifests, generate thumbnails, and run content checks. A workflow engine tracks progress, retries failed tasks, and marks the video READY.

Playback. The player gets metadata and a manifest URL from the video API, then fetches segments from the nearest CDN edge. The player's adaptive bitrate logic picks a rendition for each segment based on throughput and buffer level.

4. Data model

videos       video_id, owner_id, title, description, status (UPLOADING | PROCESSING |
             READY | FAILED | REMOVED), duration_s, created_at, visibility
renditions   video_id, codec, resolution, bitrate, manifest_path, storage_tier
upload_sessions  session_id, video_id, chunk_size, chunks_received, expires_at
view_counts  video_id, count            -- updated asynchronously from a view-event stream

Metadata is read-heavy and small; a sharded relational or wide-column store keyed by video_id, with a cache in front, is plenty. View counts are high-write: aggregate view events in a stream processor and update counts in batches, as in a top-K system.

5. Scaling delivery and storage

• CDN first. Popular videos are cached at the edge; a long tail is served from regional caches or origin. Pre-position new videos from popular creators at the edge before they trend.
• Segment size: shorter segments (2–4 s) adapt faster and start faster; longer ones are more efficient to serve.
• Storage tiering: keep hot renditions in standard object storage, move cold videos to cheaper tiers, and consider dropping rarely watched high-bitrate renditions (they can be regenerated from the source).
• Encoding efficiency: newer codecs cut bandwidth substantially at the cost of more encoding compute and narrower device support; encode popular videos in more codecs than unpopular ones.
• Transcoding capacity: autoscale workers on queue depth; prioritise short videos and popular creators so most uploads finish quickly.

Measuring playback quality

Players should report quality-of-experience events: time to first frame, rebuffering ratio (time stalled ÷ time watched), average bitrate, rendition switches, and playback errors, tagged with CDN, region, ISP and device. Aggregate them in a stream processor so you can spot a misbehaving CDN edge or a bad encoder release within minutes, and so you can steer traffic away from poorly performing CDN providers automatically.

6. Trade-offs to call out

• Encode everything vs encode on demand: encoding all renditions up front costs compute and storage for videos nobody watches; encoding lazily delays first playback at some qualities.
• Own CDN vs commercial CDN: at very large scale, placing caches inside ISPs pays off; smaller platforms buy CDN capacity.
• Consistency of counts: exact real-time view counts are expensive; approximate, slightly delayed counts are fine.
• Latency vs cost in processing: more parallelism finishes faster but costs more per video.

How to present this in 45 minutes

Scope first: "user uploads plus on-demand playback; live streaming and recommendations out of scope." Spend a few minutes on estimates and land on the two big numbers, storage per day and peak egress, because they justify object storage and the CDN. Draw the diagram in two halves, upload/processing then playback, and walk one video through each. Use the deep dive on whichever half the interviewer prefers: the transcoding DAG and its retries, or adaptive bitrate and CDN behaviour. Close with cost (storage tiering, codec choice) since that's where real platforms spend their effort.

7. Common follow-up questions

1. How would you add live streaming? Ingest over a streaming protocol, transcode in real time into short segments, and publish a manifest that updates every few seconds; low-latency variants use smaller partial segments.
2. How do you prevent unauthorised downloads of paid content? DRM with encrypted segments and licence servers, plus signed, expiring CDN URLs.
3. How do you handle a video that suddenly goes viral? The CDN absorbs it; make sure origin shielding is on so a burst of edge misses doesn't stampede origin.
4. How does search work? Index metadata and transcripts asynchronously in a search cluster.
5. How do you resume an interrupted upload? The upload session tracks which chunks arrived; the client asks for the session state and sends only missing chunks.