Design a Video Streaming Platform

From upload to adaptive playback

Split the system into an upload path and a watch path. Upload: the client gets a pre-signed URL and uploads the original (often in resumable chunks) directly to object storage; an event triggers a transcoding pipeline that splits the video into segments, encodes several renditions (resolutions and bitrates) in parallel workers, generates thumbnails, and writes outputs plus a manifest. Watch: players fetch an HLS or DASH manifest listing renditions, then download short segments from a CDN; adaptive bitrate (ABR) logic in the player switches rendition based on measured bandwidth and buffer. Metadata (titles, owners, status) lives in a database; view counts are aggregated asynchronously.

Upload and delivery pipeline

Simplified flow.

UPLOAD
client --request upload--> API --pre-signed URL--> client
client --chunks--> object storage (raw/)
storage event --> queue --> transcode orchestrator
   -> split into segments -> workers encode renditions in parallel
      (e.g. 1080p, 720p, 480p, 240p; choose a ladder per content)
   -> write segments + HLS/DASH manifests to storage (processed/)
   -> mark video READY in metadata DB

WATCH
player --GET manifest--> CDN (miss -> origin storage)
player --GET segment N at chosen bitrate--> CDN
player measures throughput + buffer -> switches rendition (ABR)

Printing one book in many formats

The publisher prints large-print, paperback and pocket editions once, ships them to local bookshops, and each reader picks the edition that suits them right now.

Quick check: What does adaptive bitrate streaming do?

• Lets the player switch between renditions based on network conditions
• Compresses video on the client before upload
• Stores one rendition per user
• Replaces the CDN