Video Streaming System Design Interview Guide: Uploads, Transcoding, Adaptive Bitrate, and CDN Delivery

A video streaming system design answer should connect an accepted upload to a playable frame. The CDN is one part of that path. The source must survive processing failures, the manifest must reference valid outputs, and the player must be able to switch quality without jumping to a different moment in the video.

Use Ingest → Transcode → Package → Deliver → Observe to organize the explanation. This guide retains that lifecycle and develops one numeric VOD asset, a short playlist fixture and a recovery trace. Rates, workload, worker speed and cost are fictional planning assumptions. The local checks model metadata and arithmetic; they do not encode or play media.

Define the product and the media contract

Clarify VOD versus live, upload distribution, device support, regions, rights, moderation, captions, retention and acceptable publication delay. Separate optional search, recommendations and social features from the load-bearing media pipeline. Ask for viewer concurrency and average delivered bitrate before estimating egress.

Practice Design video platform and catalog system. This verified Apple-tagged PracHub record asks for video ingestion, transcoding, tiering, CDN delivery and traffic estimates alongside a separate marketplace-catalog design. Use its video portion here; the record is practice context, not a promise of an interview question.

Control APIs manage asset records, upload sessions, jobs and playback authorization. Object storage and CDN paths move the large bytes. Do not run a multi-gigabyte upload or a long encode inside one metadata request.

Worked asset: thirty minutes, three renditions

Original planning case. Asset A17 has immutable source s3, encoding profile p2 and a 1800-second duration. Assume a 15-Mbps average source and three compatible audio/video renditions averaging 0.8, 2 and 4 Mbps. Each rate includes the audio carried in that rendition. We deliberately duplicate muxed audio rather than assume a separate shared audio track.

Use decimal units: 1 MB = 10^6 bytes and 1 GB = 10^9 bytes. For average rate b Mbps over t seconds, bytes in GB are b × t / 8000. Packaging overhead, initialization files, subtitles, thumbnails, indexes, redundant copies and temporary attempts are excluded.

Four-second boundaries create 450 media segments per rendition, or 1350 media objects. Add initialization sections and playlists separately. Average segment size is a planning value; variable bitrate can make individual segments larger, so measure peaks when authoring bandwidth declarations and player tests.

At 1000 such uploads/day and 30 days of hot retention, source plus renditions require (3.375 + 1.53) × 1000 × 30 = 147150 GB, or 147.15 TB for one copy. Keeping a second complete output profile for every retained asset adds another 45.9 TB before overhead. Reprocessing and rollback retention are therefore capacity decisions, not free metadata changes.

Encoding capacity depends on the deadline

Assume one worker encodes one rendition at twice media speed. This is a fictional planning speed, not an FFmpeg benchmark. Daily work is 1000 × 1800 × 3 / 2 = 2700000 worker-seconds, or 750 worker-hours. At a 70% planning utilization, a 24-hour completion window needs ceil(750 / (24 × 0.7)) = 45 slots.

If all daily uploads arrive together and must finish in four hours, the same arithmetic needs 268 slots. The average daily calculation cannot support that burst deadline with 45 workers. Actual sizing must include codec/content variation, setup, probe, packaging, failures and measured throughput; utilization headroom is not a latency guarantee.

Separate short and long assets, cap tenant concurrency and expose oldest-job age. Retry infrastructure failures with bounds; quarantine deterministic invalid media. Prioritize required outputs according to the publication contract rather than letting an expensive optional codec block every upload.

Accept and seal the source without losing recovery

Create an asset and an upload session. Give the uploader scoped destinations and persist authoritative offset or part state. On reconnect, recover the server’s progress instead of trusting the client’s last attempted byte. The tus protocol rejects an incorrect upload offset without modifying the resource. S3 multipart upload offers a provider-specific initiate, part, checksum, complete and abort flow. tus protocol, S3 multipart upload.

Application finalization verifies expected length, checksum, media type and policy, then associates the stored object with one immutable source version. Object-store completion and a database transition are different boundaries. Reconcile a completed object with a still-open session after a crash; an idempotent application completion returns the existing sealed version.

Persist source lineage and job intent together where the database permits it, using an outbox or equivalent durable handoff. A failed notification must not leave a sealed asset permanently unprocessed. Scope masters privately and retain them through any permitted retry/reprocessing window.

Transcode and package through explicit versions

Use separate asset, source, processing-job and output records. Jobs identify source s3, profile p2, requested rendition and current attempt. The media probe establishes duration, tracks, timestamps and decoding constraints. FFmpeg’s documentation describes demuxing, decoding, filtering, encoding and muxing; your job graph coordinates those operations and records their versions. FFmpeg documentation.

A worker writes into its attempt’s isolated output path. It must not overwrite a previously published object. Register a candidate only if the current attempt still owns the commit and the expected source/profile versions match. A lease alone cannot prevent an expired worker from returning late; enforce authority at registration.

Make validation include referenced objects, timelines, required tracks, intended codec/device compatibility and random-access boundaries. A list of object names is necessary but insufficient: actual media inspection and sampled playback matter. Do not label a manifest ready merely because storage listings contain 1350 keys.

A complete twelve-second HLS metadata fixture

The following is a separate twelve-second teaching fixture, not the full thirty-minute A17 playlist. It has three four-second segments per rendition. URLs are relative to an immutable release directory. The declared peaks of 1, 2.5 and 5 Mbps are hypothetical; production declarations must follow measured media, not guesses.

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-STREAM-INF:BANDWIDTH=1000000,AVERAGE-BANDWIDTH=800000
low/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,AVERAGE-BANDWIDTH=2000000
mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,AVERAGE-BANDWIDTH=4000000
high/index.m3u8

The middle rendition’s complete media playlist is:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:4
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-MAP:URI="init.mp4"
#EXTINF:4.000,
seg-000.m4s
#EXTINF:4.000,
seg-001.m4s
#EXTINF:4.000,
seg-002.m4s
#EXT-X-ENDLIST

The low and high playlists use the same duration boundaries with their own initialization and media objects. RFC 8216 defines the multivariant/media playlist relationship and fMP4 initialization mapping. The fixture includes EXT-X-MAP, a compatible protocol version and an end marker. These files contain metadata only; no segment binaries were generated. HTTP Live Streaming, RFC 8216.

At playback, the client selects and adapts a rendition using throughput, buffer and device constraints. Switching at the eight-second boundary must continue the same presentation timeline. A playlist duration sum of twelve seconds does not establish aligned decode timestamps, codec compatibility or a successful switch. Validate actual encoded outputs on supported players.

Partial transcode failure: preserve the playable release

Suppose A17 already serves release g1. A p2 reprocess builds g2, but high rendition segment 449 is absent. The product requires all three renditions, so hold g2; g1 remains active. If a reduced ladder is allowed, create a separately validated manifest that omits the failed rendition rather than advertising a missing path.

An in-memory metadata model exercised this sequence. It checks a current attempt, the exact required reference set, mock-object presence and an expected publication revision. Mock objects are assumed immutable and retained. This is not a durable registry or a real transcoder failure test.

The pointer’s revision advances even when rollback returns to an old release, avoiding an ABA-style “same pointer, therefore unchanged” assumption. Registration authority and publication authority are separate checks. An actual service needs transactional persistence, authorization, object-retention policy and tests of concurrent operations and crash points.

Keep older release paths readable for existing sessions. New sessions can receive the new pointer while earlier viewers continue their pinned manifest. Rollback changes new-session routing; it cannot recall bytes already served. Garbage-collect outputs only after proving they are unreferenced by active releases and retained sessions under the chosen policy.

Delivery, egress and the shorter-segment follow-up

Authorize a playback session before returning access to an immutable manifest. Cache media bytes under versioned keys while maintaining access control at the appropriate boundary. Tokens, manifests and user metadata have different privacy/freshness needs. HTTP cache policy needs explicit freshness and validation rules; long-lived segment caching is safe only while the bytes and their meaning stay immutable. HTTP caching, RFC 9111.

At 10000 concurrent viewers averaging 2 Mbps, delivery is 20 Gbps, or 216 TB/day if sustained for the entire day. With an assumed 95% byte cache-hit ratio, origin media traffic is 10.8 TB/day. This is a byte ratio, not a request-hit ratio; cold starts, popular releases and regional failure can invalidate the steady-state assumption.

Using a fictional all-inclusive egress rate of $0.02/GB gives $4320/day. This is a planning example, not a current provider quote. Real cost includes regional tiers, request charges, storage, encoding, duplication and origin traffic; do not apply one illustrative rate as an actual bill.

Now shorten segments to two seconds. Each rendition has 900 segments, producing 2700 media objects. Under the unchanged bitrate assumption, rendition payload remains 1.53 GB, while steady sequential media GETs rise from 10000 / 4 = 2500/s to 5000/s. Actual payload and encode efficiency may change with keyframe frequency; initialization, retries, prefetch and manifests add requests. Shorter chunks can improve responsiveness while increasing overhead, and do not by themselves produce a live-streaming architecture.

Observe and defend the whole path

Track checksum failures, sealed assets without jobs, queue age, encoding time by profile, invalid manifests and missing outputs. Collect client startup time, playback failure, rebuffer ratio, quality switches and exit-before-start. Keep identifiers appropriate to the telemetry purpose. A successful processing HTTP response does not establish a playable release.

The local run passed 32 checks of arithmetic, generated playlist metadata and the six-step publication model. It established the stated counts, candidate rejection and pointer transitions. It did not test codecs, actual media alignment, live storage, worker crashes, CDN behavior or player quality. Those are the next validation layers.

For a 45-minute practice, spend five minutes clarifying scope, seven defining APIs and versions, ten tracing ingest/jobs, ten explaining packaging/player behavior, eight breaking the pipeline and five closing with capacity, rights and QoE. These are mock allocations, not an employer schedule. Change one deadline, segment duration or retention policy and redo the affected numbers.

Frequently asked questions

How should large video uploads be handled?

Create a resumable session and let the client upload directly to scoped storage destinations. Verify completeness, length, checksums and media policy before sealing an immutable source version. Repeated application-level finalization should return the same result and avoid duplicate job intent.

How much storage does the worked VOD asset need?

Under the fictional average rates, a 30-minute 15-Mbps source is 3.375 decimal GB. The 0.8, 2 and 4-Mbps renditions total 1.53 GB, giving 4.905 GB before packaging overhead, copies and supporting assets. At 1000 assets/day and 30 days, that is 147.15 TB.

Why must ABR segments align?

The player switches between representations of the same media timeline. Compatible boundaries and random-access frames let the next segment continue playback. Matching playlist durations alone does not prove decoder compatibility; actual media and supported devices need validation.

What happens when one transcode fails?

Keep the previous playable release. Retry under a current attempt token and validate every required rendition before publication. If a reduced ladder is allowed, publish an explicitly validated reduced version. Never advertise a missing output merely because another rendition succeeded.

Can a VOD design be reused for live streaming?

Some components transfer, but live publishing advances continuously rather than waiting for a complete validated asset. Latency, clock alignment, partial failure, buffering and backpressure become immediate constraints. Define that contract separately instead of assuming shorter VOD segments create a live service.

Sources and scope

• tus resumable upload protocol.
• S3 multipart upload overview.
• FFmpeg documentation.
• HTTP Live Streaming, RFC 8216.
• HTTP caching, RFC 9111.

Checked October 9, 2026. All workload, pricing and performance inputs are fictional. The local metadata model has no durable storage or media binaries; its checks are not production recovery or playback evidence. Live streaming requires a separately defined continuous-publication contract.