Design: video streaming

The full lesson, with a worked example: Design: a video streaming service. The viewer's side is in Video streaming: why it buffers.

Requirements

Functional

• Upload: creators upload videos of any length from phones or laptops.
• Watch: on any device and connection, with pause and jump-anywhere.
• Details: title, thumbnail, view count, likes.

Non-functional

• Fast start: playback within about 2 seconds, and rare stalls.
• Uploads never lost: processing may take minutes, but an accepted upload is safe.
• Available: survives a server or a whole data centre failing.
• Viral-proof: copes when one video suddenly gets crores of views.
• Out of scope (say so): search, recommendations, comments and live streaming.

Estimates

• Uploads: 1 lakh videos a day × 8 minutes ≈ 13,000 hours of new video a day, about one upload a second.
• Watching: 2 crore viewers × 30 minutes = 1 crore hours a day. That is about 770 hours watched per hour uploaded: extremely read-heavy.
• Concurrency: 60 crore minutes ÷ 1,440 ≈ 4 lakh watching at once on average, about 12 lakh at the evening peak.
• Peak bandwidth: 12 lakh × 2 Mbps ≈ 2.4 terabits a second. No single building's link carries that.
• Daily egress: 1 crore hours × about 0.9 GB per hour ≈ 9 petabytes a day. At an example ₹1 per GB, about ₹90 lakh a day. Bandwidth, not requests, is the main cost.
• Storage: all qualities of one hour ≈ 5 GB, so 13,000 hours ≈ 65 TB a day, about 25 PB a year, plus originals.
• Transcoding: about one CPU-hour per quality per hour of video: 13,000 × 5 ≈ 65,000 CPU-hours a day ≈ 2,700 cores around the clock, more in the evening.
• Segments: a 12-minute video in 4-second pieces is 180 pieces per quality, 900 for five qualities.

API

• POST /v1/videos: title, size, content type. Returns videoId and a signed URL for a resumable upload straight into raw storage. Video bytes never pass through the API.
• POST /v1/videos/:id/complete: the client says all pieces are in; the service queues processing.
• GET /v1/videos/:id: title, owner, status (processing, live, blocked), counts, and a signed, short-lived manifest URL.
• GET on the manifest and on each segment: plain cacheable files served by the CDN, for example /v/123/720p/seg_00042.m4s.
• POST /v1/videos/:id/views: batched view and watch-time events from the player.
• Webhook or notification when processing finishes.

Data model

• videos (metadata DB): videoId, ownerId, title, status, durationSec, manifestPath, qualities, createdAt. Small rows, very many reads; cache heavily.
• transcode_tasks: videoId, chunkIndex, quality, status, attempts, leaseUntil. One row per chunk-and-quality task.
• Object storage: raw/videoId/original, v/videoId/quality/seg_NNNNN, v/videoId/master.m3u8, thumbnails. Immutable files, so they cache forever.
• view_counts: videoId → count, updated every minute from a stream, not per view.
• fingerprints: media fingerprints registered by rights owners, checked during processing.

High-level design

1. 1

   Viewer appAPI servers

   Open video v-123

2. 2

   API serversVideo info

   Title, likes, manifest address

3. 3

   API serversViewer app

   Details + signed manifest link

4. 4

   Viewer appCDN edge

   Manifest, then pieces 1 and 2 at 480p

5. 5

   CDN edgeRegional hub

   Piece 2 not here: ask once

6. 6

   Regional hubVideo storage

   Rare miss: fetch from origin

7. 7

   CDN edgeViewer app

   Playback starts in about 1 s

8. 8

   Viewer appCDN edge

   Fast network: piece 3 onwards at 1080p

Two paths that barely touch:

• Upload path: slow, heavy, rare. Signed link → raw object storage → a job on a queue → transcode workers → video storage.
• Watch path: light per request, enormous in total. The API hands out metadata and a manifest link, then steps aside. The player fetches pieces from the nearest CDN edge.

1. 1

   CreatorUpload service

   New video, 1.8 GB

2. 2

   Upload serviceCreator

   Signed link to raw storage

3. 3

   CreatorRaw storage

   8 MB pieces, resumable

4. 4

   Upload serviceJob queue

   12 chunks × 5 qualities = 60 tasks

5. 5

   Job queueTranscode workers

   Tasks in parallel

6. 6

   Transcode workersVideo storage

   Segments + manifest, low first

7. 7

   Upload serviceCreator

   Live at 480p; 1080p soon

Deep dives

Transcoding in parallel

• Transcoding decodes the original and re-encodes it at several sizes and rates: the bitrate ladder, say 1080p at 5 Mbps, 720p at 3, 480p at 1.5, 240p at 0.4.
• Segments: each quality is cut into 2 to 6 second segments, listed in a manifest.
• Split the work: cut the original into one-minute chunks and give each chunk-and-quality to a different worker. A 12-minute video becomes 60 tasks that finish in minutes, not an hour.
• Publish low first: 240p and 480p go live while 720p and 1080p finish.
• Crash-safe: a task is marked done only when its output is stored. If a worker vanishes, the task returns to the queue after a timeout; repeated failures go to a dead-letter queue.
• Also in the pipeline: thumbnails, copyright fingerprint checks, harmful-content checks.

Adaptive bitrate in the player

The player keeps a buffer of a few pieces ahead and picks each next piece's quality from how fast the last ones arrived: adaptive bitrate. It starts low for a quick first picture, steps up while the network keeps up, and drops before the buffer runs dry. In a tunnel it falls to 240p and keeps playing on 20 to 30 buffered seconds, then climbs back one rung at a time. Seeking to minute 40 just means asking for piece 600.

CDN tiers and the long tail

• Edge in the viewer's city serves most requests; misses go to a regional hub, and only the hub's misses reach the origin. About 95% of segment requests never leave the edge.
• Hits: this week's popular videos stay at every edge with a hit rate near 100%.
• The long tail: crores of rarely watched videos are fetched from origin on demand. That's fine.
• Viral in one city: request coalescing sends one upstream fetch per piece while thousands of viewers wait a few milliseconds for it.
• Known releases: copy episodes to every edge in the quiet hours (pre-warming), so midnight is all cache hits.

Counting views and cutting storage

• Views: players send events into a stream; stream processing adds them up per minute. Never "add 1" to one row per view, which locks a viral video's row thousands of times a second. Show an approximate count; work out exact numbers later for creator payments.
• Cold videos: a lifecycle rule moves originals to cold storage and can drop middle qualities, re-creating them if a video comes back.
• Paid films: DRM encryption, so copied pieces are useless without a licence key.

Trade-offs

• Shorter segments: faster start and quality switches, but more files, more requests and slightly worse compression.
• More ladder rungs: smoother switches, but more transcoding and storage for every video, including ones nobody watches.
• Newer codecs: about 30 to 50% smaller files for the same picture, but far more CPU to encode and older phones can't play them, so you keep an older format too.
• Publish low qualities first: live sooner, at the cost of a few minutes of soft picture only.
• Own boxes inside internet providers vs renting a CDN: cheaper per GB at huge scale, but a big upfront and operational cost.

Interview talking points

• Lead with the ratio (about 770:1) and the peak bandwidth in terabits a second: the problem is bytes and geography.
• Two separate paths, and video bytes never touch the API servers.
• Resumable upload via signed URL; transcoding queued, chunked and parallel; low qualities first.
• Segments, ladder and manifest are what make adaptive bitrate and seeking possible.
• CDN tiers, hit rates, the long tail, coalescing and pre-warming.
• Metadata in a database; view counts through a stream; storage tiers for old videos.
• Metrics: startup delay, rebuffer ratio, average delivered bitrate, per ISP and device.

Follow-up questions

How do you get playback to start in under 2 seconds? Start at a low quality with small first pieces, serve them from an edge in the viewer's city, and pre-fetch the opening pieces of videos the viewer is likely to tap next.

How would live streaming change the design? Transcoding must keep up within seconds, segments are shorter and the manifest keeps growing. There's no time to pre-position, so edges fetch new pieces the moment they exist and request coalescing becomes essential.

Your bandwidth bill doubled. Where do you look? The CDN hit rate per region, the average delivered bitrate (did a default change to 1080p?), and whether a newer, smaller codec can be served to devices that support it.

A worker dies halfway through a long video. What happens? Only that chunk-and-quality task is lost. Its lease expires, it goes back on the queue, and another worker redoes about a minute of video.

Someone uploads a cinema release, cropped and colour-shifted. How do you catch it? Byte comparison fails, so compute a media fingerprint of picture and sound during processing and match it against fingerprints rights owners registered, before the video is published.