Design a video streaming platform

Expected question

"Design a video streaming platform (YouTube/Netflix-style). How do you upload, transcode, store, and deliver video with adaptive bitrate streaming?"

Variant forms

Same design, different framing:

• "Design upload → transcode → CDN delivery for user-generated video."
• "How do you implement adaptive bitrate (HLS/DASH) for variable network conditions?"
• "Design live streaming with <5 second glass-to-glass latency at scale."
• "Our transcoding queue backs up during peak — architect priority and autoscaling workers."
• "Design DRM and geo-restriction without breaking CDN cache efficiency."
• "How do you generate thumbnails, captions, and moderation scores in the pipeline?"
• "Design view-count aggregation that's accurate but not write-heavy on every play."

Where this actually gets asked

Classic hard system-design (YouTube/Netflix-style): upload, transcode, CDN delivery, adaptive bitrate. Appears at Netflix, Google, Meta; Staff+ probes encoding pipelines and global delivery cost.

Executive summary

30-second thesis

I'd separate resumable upload/origin from playback CDN, async-transcode into an ABR ladder (HLS/DASH), and measure rebuffer ratio — not just CDN hit rate.

2-minute answer

Clarify UGC vs catalog, live vs VOD (live is a different design — say so), and geo/DRM needs. Default: create → resumable PUT to object store → complete → job queue → parallel renditions → packager writes playlists/segments → mark ready → player fetches master playlist from CDN. Signed short-lived playback URLs for private content. Origin shield + coalescing on viral cold starts. Cold storage lifecycle for long-tail. Views counted async. In 45 minutes nail upload→transcode→ABR; defer recommendations and full live stack unless asked.

Quantitative trade-offs

What I'd ask them

1. VOD only, or live in the same interview?
2. Max upload size and target startup / rebuffer SLOs?
3. DRM / geo-restrict required?

Requirements

Functional

• Upload video (resumable); process into multiple renditions.
• Playback with adaptive bitrate (HLS/DASH).
• Metadata: title, thumbnails, visibility; basic view counts.
• Optional: live streaming as a follow-up (different design — call out).

Non-functional

• Upload reliability for multi-GB files; processing async.
• Startup time and rebuffering SLOs globally via CDN.
• Storage cost dominates — lifecycle cold storage for rarely watched.
• Copyright / abuse takedown path.

Core entities

• Video asset: id, owner, status (uploading|processing|ready|failed), duration.
• Rendition: resolution, bitrate, codec, object_uri, playlist_uri.
• Playback session: user, CDN edge, chosen rendition ladder.
• Processing job: ffmpeg pipeline steps, retries.

API / interface

POST /v1/videos
{ "title":"...", "visibility":"public" }
→ 201 { "video_id":"v_...", "upload":{"url":"https://upload/...","method":"PUT"} }

PUT upload URL (chunked / resumable)
→ 200

POST /v1/videos/{id}/complete-upload
→ 202 { "status":"processing" }

GET /v1/videos/{id}
→ { "status":"ready", "playback_url":"https://cdn/.../master.m3u8", "thumbnails":[...] }

GET /v1/videos/{id}/analytics
→ { "views":..., "watch_time_sec":... }

Staff+ callout: separate upload/origin from playback CDN trust boundaries.

Data Flow

Client uploads to object storage → complete → transcoder workers produce renditions + HLS playlist → publish to CDN → player fetches ABR ladder; views counted asynchronously.

Rendering architecture diagram…

High-level design

Rendering architecture diagram…

Deep dive 1: transcode pipeline

Parallelize per-rendition; idempotent jobs; dead-letter poison files. GOP alignment matters for ABR switching. Thumbnails and previews are separate cheap jobs.

Deep dive 2: CDN and ABR

Pre-warm popular titles; origin shield to protect object store. Player picks rung by bandwidth; measure rebuffer ratio as the product SLO, not just CDN hit rate. See cache/CDN patterns in 07.

Deep dive 3: cost and cold storage

Move cold videos to cheaper storage class; keep hot segments on CDN. Precompute vs just-in-time transcode trade-off for long-tail catalogs.

Deep dive 4: signed playback and origin protection

Private/unlisted playback uses short-lived signed URLs (upload creds ≠ playback creds). On CDN cold start for a viral title, use origin shield + request coalescing so origin survives a global miss storm — otherwise rebuffer SLOs die while "RTO" looks fine. In 45 minutes, upload→transcode→ABR; live streaming is a separate follow-up.

What's expected at each level

• Mid-level: upload to S3, play from URL.
• Senior: async transcode + CDN + HLS.
• Staff+: resumable upload, rendition parallelism, ABR/rebuffer SLOs, cost tiers.
• Principal: global capacity planning and live-vs-VOD split when asked.

Follow-up questions to expect

• "Design live instead?" — Different beast: ingest servers, low-latency HLS/WebRTC, tighter SLAs. Don't stretch the VOD pipeline and call it live.
• "Where do recommendations fit?" — Separate system — see ai-system-design/06.

Related

• 07 Distributed cache / CDN
• 04 Job scheduler