Design a Video Streaming Platform: Upload, Transcoding and Adaptive Streaming

When you press play on a video, the first frame appears within a second or two, and if your train enters a tunnel the picture gets blurrier for a moment instead of freezing. Behind that are two large systems. One takes a creator's 4 GB upload over a patchy connection, turns it into dozens of versions at different qualities, and stores them. The other delivers small pieces of those versions to millions of viewers at once, from servers close to each of them.

An exercise in article 06 estimated that 50 million daily viewers watching 30 minutes each at 5 Mbps need roughly 10 terabits per second at peak; with a more realistic mix of qualities, this article arrives at about 8. This case study designs the platform that makes that possible. It is the first Level 3 case study: several pipelines, enormous byte volumes, and asynchronous processing everywhere.

• How to estimate a byte-dominated system: ingest, storage, compute and egress.
• Resumable uploads of very large files.
• A parallel transcoding pipeline and how to orchestrate it reliably.
• Adaptive bitrate streaming: renditions, segments and manifests.
• CDN delivery, caching rules, access control and multi-CDN.
• Storage tiering, view counting, failures and observability.

Build a video-on-demand platform where creators upload videos and viewers watch them on phones, laptops and TVs over networks ranging from fast fibre to weak mobile data. Videos must start quickly and keep playing smoothly as bandwidth changes.

Functional requirements: upload a video; process it into streamable formats with thumbnails; stream with adaptive quality; show metadata and view counts; delete videos.

Non-functional requirements

All figures below are assumptions for this exercise.

Uploads and ingest

200,000 uploads/day; average raw size 300 MBIngest: 60 TB/day -> about 700 MB/s, about 5.6 Gbps on average

Stored renditions (a ladder of 5 qualities with assumed bitrates):

240p 0.4 Mbps + 360p 0.8 + 480p 1.5 + 720p 3 + 1080p 6 = 11.7 Mbps for all renditions togetherAverage video 5 minutes = 300 s -> 11.7 x 300 / 8 = about 440 MB of renditions per video200,000 videos/day x 440 MB = about 88 TB/day of renditions; about 32 PB/yearPlus originals: 60 TB/day, about 22 PB/year (kept for re-processing; can move to archive storage)

Viewing and egress

50 million DAU x 30 minutes/day; average delivered bitrate 2.5 Mbps (mix of qualities)Concurrent viewers on average = 50M x 30 / 1,440 minutes = about 1.04 millionAverage egress = 1.04M x 2.5 Mbps = about 2.6 Tbps; peak (factor 3) about 7.8 Tbps

Transcoding compute (an assumption to replace with measurements for your codec settings): producing the whole ladder takes about 10 CPU-minutes per minute of video.

200,000 videos x 5 minutes x 10 CPU-minutes = 10 million CPU-minutes/day/ 1,440 minutes = about 6,900 CPU cores busy on average (more at peak upload times)

Conclusions: egress (terabits per second) and storage (tens of petabytes a year) dwarf everything else. The design must push delivery to CDNs, store bytes in object storage with tiering, and run transcoding as a large, elastic, parallel batch system. The metadata database is small by comparison.

POST /v1/videos{ "title": "Monsoon trek to Kudremukh", "size_bytes": 4200000000, "content_type": "video/mp4", "visibility": "public" }201 { "video_id": "v_9a1", "upload": { "upload_id": "...", "part_size": 104857600,       "part_urls_endpoint": "/v1/videos/v_9a1/upload-parts" } }POST /v1/videos/{videoId}/upload-parts {"part_numbers": [1,2,3]}  -> presigned URLs for those partsPOST /v1/videos/{videoId}/complete     {"parts": [...]}            -> 202 { "status": "processing" }GET  /v1/videos/{videoId}200 { "status": "ready", "duration_s": 312, "thumbnail_url": "...",      "playback_url": "https://cdn.example/v_9a1/master.m3u8?sig=..." , "views": 18234 }POST /v1/playback-events    (batched from players: start, quality switches, rebuffering, progress)DELETE /v1/videos/{videoId}

The upload API hands out presigned URLs per part, so bytes go straight to object storage (article 10); our servers handle only metadata. Playback URLs point to the CDN and are signed for private or unlisted videos.

videos            (video_id PK, owner_id, title, description, visibility, status                   (uploading, processing, ready, failed, blocked, deleted), duration_s,                   original_key, renditions (list of quality and path), created_at, published_at)                   index (owner_id, created_at DESC)processing_jobs   (video_id, step, chunk, rendition, status, attempts, output_key, updated_at)                   PK (video_id, step, chunk, rendition)       -- one row per unit of workview_counts       (video_id, day, views)                         -- aggregated, eventually consistentObject storage layout (immutable objects, deterministic keys):  raw/v_9a1/original.mp4  work/v_9a1/chunks/00017.mp4  hls/v_9a1/1080p/segment_00017.ts      (or fragmented MP4 segments)  hls/v_9a1/1080p/index.m3u8  hls/v_9a1/master.m3u8  thumbs/v_9a1/0003.jpg

Deterministic object keys make processing steps idempotent: rerunning a step overwrites the same objects with identical content.

Creator --upload--> App server (stores the file on disk) --> serves the MP4 file to viewers

A single file served from our servers: uploads tie up app servers, a 4 GB upload restarts from zero on any network drop, viewers on slow networks buffer constantly because there is only one quality, viewers far away wait on long round trips, and our servers would need to push terabits per second.

1. Uploads: large files through app servers, no resume.
2. One quality for everyone: 1080p stalls on mobile data; 240p looks terrible on a TV.
3. Transcoding time: encoding a long video sequentially into five qualities can take longer than the video itself.
4. Egress: terabits per second cannot come from our origin.
5. Storage growth: tens of petabytes a year.
6. Popular videos: a viral video concentrates traffic on a few objects.

The client splits the file into parts (here 100 MB), uploads them in parallel to object storage with presigned URLs, retries only failed parts, and can resume after the app restarts by asking which parts are already present. Amazon's S3 documentation describes multipart upload for exactly this: parts uploaded independently and in any order, failed parts retransmitted without affecting others, pause and resume, and a recommendation to use it for objects of 100 MB or more (Multipart upload). On completion, the object store assembles the original, and an object-created event (or the client's complete call) starts processing.

Upload complete  -> 1. Validate: real container and codec, duration, size limits; malware scan  -> 2. Probe: resolution, frame rate, audio tracks  -> 3. Split into chunks of about 10 seconds, at keyframe boundaries  -> 4. Transcode: for each chunk x each rendition, one task  (fan-out: a 5-minute video        = 30 chunks x 5 renditions = 150 parallel tasks)  -> 5. Assemble and package: per rendition, segment and write a media playlist; then the master playlist  -> 6. Thumbnails and preview sprites  -> 7. Moderation and copyright checks (automated, with human review for flagged items)  -> 8. Publish: write the master playlist last, set status = ready, emit VideoReady

• Orchestration: a workflow engine or a saga orchestrator (article 21) tracks each video's steps in processing_jobs, schedules tasks onto queues, and retries failures. Each task is small (one chunk, one rendition), so failures cost little to redo.
• Workers are a large, autoscaled fleet of competing consumers (article 11; Competing Consumers), scaled on queue depth, often on cheaper interruptible capacity since tasks are short and retryable.
• Parallelism turns a 2-hour video's transcoding from hours into minutes, limited mainly by how many workers you can give it.
• Priorities: short videos and verified creators can go to faster queues; very long uploads to a separate queue so they do not starve everyone else.
• Idempotency: tasks write to deterministic keys; the orchestrator marks a task done only after its output exists; duplicates simply overwrite identical objects.
• Re-processing: keeping originals lets you re-encode the library when a better codec arrives, as a background batch job.

Instead of one file, each rendition is cut into segments a few seconds long, and playlists (manifests) describe them:

master.m3u8                      lists the renditions and their bandwidths  240p/index.m3u8   -> segment_00001.ts, segment_00002.ts, ...  480p/index.m3u8   -> ...  1080p/index.m3u8  -> ...

The player downloads the master playlist, starts with a modest rendition (for a fast start), measures download speed as it fetches segments, and switches rendition at segment boundaries: up when bandwidth allows, down before its buffer runs out. HTTP Live Streaming (HLS), specified in RFC 8216, defines this playlist and segment format (RFC 8216, HTTP Live Streaming); MPEG-DASH is a widely used alternative built on the same idea. Because segments are ordinary files fetched over HTTP, any CDN can serve them.

Choices worth stating:

• Segments and VOD playlists are immutable: give them long cache lifetimes (Cache-Control: public, max-age=31536000, immutable). A popular video's segments are served almost entirely from CDN edges after the first viewers in each area. A CDN such as CloudFront delivers content from edge locations close to viewers (What is Amazon CloudFront?).
• An origin shield (a mid-tier cache between edges and object storage) collapses requests from many edges, so a viral video does not create thousands of origin fetches.
• Pre-warm edges for scheduled premieres.
• Changes use new paths (re-processed videos get a new version prefix) rather than invalidation; CloudFront's documentation recommends versioned file names over invalidation for frequently updated files (Invalidating files). Invalidation is kept for takedowns.
• Multi-CDN: at terabits per second, many platforms use more than one CDN and steer traffic by cost and performance per region; a CDN outage then degrades, rather than stops, playback.

With 95% of bytes served from cache, origin egress at the 7.8 Tbps peak is about 390 Gbps, still large, which is why the shield and long TTLs matter so much.

Viewing is highly skewed: most views go to recent and popular videos. Lifecycle rules move originals to archive storage after processing, and renditions of rarely watched videos to cheaper infrequent-access tiers (keeping the most-used renditions hot). Some platforms even delete the highest renditions of videos nobody watches and regenerate them on demand from the original.

Players send batched playback events (start, progress, quality changes, rebuffering) to an ingestion endpoint, which writes them to an event stream (article 11; Kafka-style streams keep events ordered per partition and retain them for replay (Introduction to Kafka)). Stream processors:

• count a view when a session passes a threshold (for example 30 seconds or a percentage of the video), deduplicating by session and filtering obvious bots;
• aggregate counts per video per minute and update view_counts, which the API serves from cache;
• compute quality-of-experience metrics (start time, rebuffering) for monitoring.

UPLOAD PATHCreator app --metadata--> Upload API --> metadata DB (status uploading)            --parts (presigned, parallel, resumable)--> Object storage (raw/)Object created --> Workflow orchestrator --> queues --> transcoding workers (autoscaled)             --> packaging --> object storage (hls/) --> moderation --> publish (status ready, VideoReady event)PLAYBACK PATHViewer app --> Metadata API (cached) --> signed playback URL           --> CDN edges (multi-CDN) --> origin shield --> object storage (hls/)Player events --> ingestion --> stream --> view counts, QoE metrics

• Publishing is atomic from the viewer's point of view: the master playlist is written last and the status switches to ready only after every rendition exists, so no viewer ever loads a playlist that references missing segments.
• Metadata, search and counts are eventually consistent (seconds to minutes).
• Deletion: metadata status changes immediately (the video stops being playable through the API, and signed URLs stop being issued), CDN caches are invalidated for takedowns, and objects are deleted asynchronously.
• Creators see their own video's processing status immediately (read from the primary).

• Upload safety: validate formats by content, not file extension; scan for malware; enforce size and duration limits; rate-limit uploads per account.
• Content safety: automated moderation and copyright matching before publishing, human review for flagged videos, and fast takedown.
• Access control: private and unlisted videos use short-lived signed URLs or signed cookies at the CDN, and the bucket accepts requests only from the CDN.
• Hotlinking and scraping: signed URLs with expiry; rate limits on metadata APIs.
• Paid content (extension): digital rights management encrypts segments and controls key delivery; it adds licence servers and device constraints.

The most important observation: the metrics that matter here are measured on the client (start time, rebuffering), because server latency says little about the viewer's experience.

"This is a byte-dominated system: about 60 TB of uploads a day, around 90 TB of renditions a day, and roughly 8 Tbps of viewing traffic at peak.

Creators upload directly to object storage with resumable multipart uploads; the API only handles metadata. Completion starts a workflow: validate and scan, split the video into 10-second chunks at keyframes, transcode every chunk into five renditions in parallel on an autoscaled worker fleet, package HLS segments and playlists, generate thumbnails, run moderation, and publish by writing the master playlist last and marking the video ready. Every task writes to deterministic keys, so retries are safe.

Viewers get a signed playback URL; the player fetches the master playlist from a CDN and adapts quality segment by segment. Segments are immutable and cached with very long lifetimes behind an origin shield, across more than one CDN, so the origin sees a few percent of bytes. Storage is tiered by age and popularity. Playback events stream into an analytics pipeline that counts views after a threshold and measures start time and rebuffering, which are the metrics we actually optimise."

Per 4K video: 16 Mbps x 300 s / 8 = 600 MBVideos per day with 4K: 20% of 200,000 = 40,000Extra per day: 40,000 x 600 MB = 24 TB; per year: about 8.8 PB

Chunks: 7,200 s / 10 s = 720Tasks: 720 x 5 renditions = 3,600One worker: 3,600 x 60 s = 216,000 s = 60 hours300 workers: 3,600 / 300 = 12 rounds x 60 s = about 12 minutes

• Next: Design a Ride-Hailing System: Location, Matching and Real-Time Updates, where the challenge is millions of tiny, constantly changing records instead of huge immutable files.
• Related: CDNs and Object Storage and the job scheduler (article 37).