A video platform cannot assume that every viewer has the same screen, decoder or network connection. Someone watching on a television over fibre can use a different stream from someone travelling on a phone whose connection changes from one minute to the next.
Adaptive streaming prepares several versions of a video and lets the player choose which pieces to download as conditions change. The architecture must connect expensive background processing with a fast, reliable playback path that can serve many viewers simultaneously.
In a system design interview, the important questions concern transcoding, packaging, manifests, player decisions and delivery. Storing the original upload is only the beginning; a stored video becomes a useful streaming product when the system can start playback quickly and keep it moving.
Introduction
We will design an on-demand video service where creators upload videos and viewers watch them through a web or mobile player. The platform prepares adaptive renditions, serves them through a content delivery network and collects playback measurements to improve quality.
The initial scope excludes live broadcasting, although we will explain how live latency changes the design. We will include captions, access control, processing failures and versioned re-encoding because these affect whether the service can operate beyond a successful demonstration.
The estimates are interview assumptions. Their purpose is to reveal which resources dominate: encoding work, stored renditions, delivery bandwidth and the large number of small requests generated by segmented playback.
Clarify Requirements and the Playback Contract
Creators can upload a supported source file and inspect its processing state. Viewers can start a published video, seek within it, select available captions and change playback quality automatically or manually.
The service should adapt to changing bandwidth and device capabilities. It should avoid publishing incomplete packages, recover from failed processing tasks and prevent unauthorised access to restricted videos.
Define a minimum playable output. A creator may prefer the video to become available once a lower-resolution rendition is ready, with higher resolutions added later. Another product may require the complete approved package before publication. Both are valid, but manifest updates and user expectations differ.
Playback quality has several dimensions. Fast start, few stalls, appropriate visual quality and stable switching all matter. Maximising bitrate alone can worsen the experience if the player repeatedly exhausts its buffer.
Assume the service prioritises reliable on-demand playback over minimum delay from upload to availability. That permits offline encoding analysis and validation. A breaking-news or live-sports platform would make different tradeoffs around processing latency and how close the viewer stays to the live edge.
Estimate Encoding, Storage and Delivery Separately
Suppose creators upload 10,000 hours of source video per day. If the system produces several renditions, encoding demand depends on resolution, codec, frame rate and content complexity, not just the number of input files.
A one-hour lecture and a one-hour high-motion sports video can require different encoding choices for comparable perceived quality. Hardware acceleration and encoder settings also change throughput, cost and output efficiency.
Assume an illustrative rendition ladder whose combined average video bitrate is twelve megabits per second. One hour across that ladder requires roughly 5.4 gigabytes of video data using decimal units, before audio, manifests, captions, source retention and replication overhead.
At 10,000 uploaded hours per day, that assumption produces about 54 terabytes of new rendition data daily. It is a planning calculation, not a recommended universal ladder. Content-aware encoding and selective rendition retention can change it substantially.
Delivery can dominate ongoing cost. One million concurrent viewers receiving an average of three megabits per second require roughly three terabits per second of video delivery. This is a strong reason to serve segments through a CDN rather than proxying every byte through application servers.
Understand Renditions, Segments and Manifests
A rendition is one encoded representation of the content, such as a particular resolution, bitrate and codec combination. Audio languages and caption tracks may be represented separately so viewers do not need to download every option.
The encoded media is divided into segments covering portions of the timeline. The player requests segments over HTTP, building a playback buffer while deciding which rendition to use for upcoming portions.
A manifest describes the available media and how to locate it. In HLS, a multivariant playlist points to variant playlists, and media playlists identify segments. The terminology has evolved, so older material may call the multivariant playlist a master playlist.
The HLS specification in RFC 8216 describes the playlist and segment model. A production implementation should also follow current platform authoring guidance, because device compatibility and newer streaming features extend beyond that baseline document.
MPEG-DASH uses a media presentation description with its own structure and timing model. The broad architecture remains similar: a player discovers compatible representations and fetches media pieces according to the presentation timeline and its current playback needs.
Build a Durable Processing Workflow
After upload completion, an ingestion service validates the source reference and creates a durable processing job. The upload itself should use a resumable or multipart mechanism appropriate to the storage platform, so a network interruption does not require restarting a large transfer from zero.
The workflow probes the source to identify duration, dimensions, frame rate, audio tracks and codecs. It rejects unsupported or malformed input according to the product's policy and records actionable errors for the creator.
Next, analysis selects encoding settings, and workers produce renditions, thumbnails, captions or other derived artefacts. Packaging creates the manifests and segment layout. Validation checks the outputs before a publication step makes the package available to viewers.
Represent these stages explicitly in durable state. A worker crash after producing several renditions should not make the entire video disappear or require guessing which files are complete. Store job attempts, source version and output references so retries can resume safely.
Use stable task identities and immutable output paths. Repeated job delivery should not cause two workers to overwrite the same partially generated segment unpredictably. A final pointer or publication record selects the validated output generation that is authoritative.
Choose the Bitrate Ladder from Quality and Compatibility
A fixed ladder offers predictable operations and broad coverage. It may include several resolutions with progressively higher bitrate targets, plus audio representations suitable for the product's device range.
However, applying the same ladder to every video can waste storage and bandwidth. A mostly static presentation may look good at a lower bitrate than detailed sports footage. Encoding a low-resolution source into a large high-resolution output cannot create missing source detail.
Content-aware analysis can select a smaller or differently spaced ladder based on quality measurements and source characteristics. AWS documents this approach in its MediaConvert automated ABR guidance. The architectural choice is to spend additional analysis and encoding effort where it reduces delivery cost or improves quality.
Codec selection adds another dimension. A newer codec can offer useful compression efficiency but may require more encoding work or lack hardware decoding on some devices. Keep compatible alternatives when the target audience needs them, and measure total cost rather than comparing only encoded file size.
Avoid creating so many near-identical renditions that the extra storage and processing provide little visible benefit. Evaluate representative content, devices and network conditions. A ladder is a product and cost decision supported by measurements, not a list of resolutions copied from another platform.
Align Segments for Clean Switching
The player should be able to switch rendition at a compatible point on the timeline. Encoders and packagers therefore need consistent segment boundaries and appropriate independently decodable access points across the representations intended for switching.
If one rendition begins a segment at a different content time, switching can produce discontinuity, decoding problems or audiovisual drift. Matching filenames or segment numbers does not prove that their media timelines align.
Frame rate, keyframe placement and timestamp handling are important here. Variable frame rate sources, discontinuities and unusual source metadata can expose packaging bugs that a simple constant-frame-rate sample will not reveal.
Apple's HLS authoring specification provides platform-specific requirements and recommendations for compatible streams. Validate against the devices you support rather than assuming that a file accepted by one desktop player will work everywhere.
Keep audio and captions aligned with the video timeline too. A stream that changes video quality smoothly but gradually loses lip synchronisation is still a failed playback experience. Validation should inspect timestamps and representative decoding, not merely confirm that every expected object exists.
Segment Duration Is a Tradeoff
Shorter segments let the player react sooner to bandwidth changes and can reduce some startup and seeking delays. They also increase request count and metadata overhead, and may reduce encoding efficiency depending on keyframe and packaging choices.
Longer segments reduce request overhead and can improve compression efficiency, but each download represents a larger commitment. If conditions deteriorate halfway through a large high-bitrate segment, the player has fewer opportunities to adapt before its buffer runs low.
For an illustrative six-second segment, one million concurrent viewers generate roughly 167,000 video segment requests per second before accounting for audio, retries, manifests and seeking. Reducing segment duration to two seconds roughly triples that video request rate under the same simplified assumptions.
The CDN and origin architecture must handle request rate as well as bandwidth. Tiny objects can create substantial per-request overhead even when aggregate bytes appear manageable.
Choose duration together with the target player, codec, packaging format and latency goals. Low-latency live streaming introduces partial segments and additional protocol behaviour; simply shrinking on-demand segments is not a complete live-streaming design.
Package for Supported Players
The packaging stage produces the protocol-specific manifests and media layout. It can run after encoding or be integrated with the encoding workflow, depending on the chosen platform and whether formats share compatible media segments.
CMAF can support common fragmented media representations across HLS and DASH in compatible configurations, reducing duplicated media storage. It does not mean every codec, encryption scheme and device combination becomes automatically interchangeable.
The DASH-IF timing model guidance describes constraints that help interoperable presentation timing. Treat packaging as a specification and compatibility problem, not merely as generating a text file containing object URLs.
Manifests need accurate bitrate, resolution, codec and timeline information. Incorrect bandwidth declarations can mislead player selection even when the media files themselves decode correctly.
Generate thumbnails and preview images as separate derived outputs if the interface supports timeline scrubbing. They can improve seeking usability without forcing the player to download full video segments just to show a preview. Keep their timing references tied to the same source generation.
Publish Packages Atomically from the Viewer's Perspective
Encoding several renditions takes time, and workers may finish at different moments. A viewer should not receive a manifest referencing segments that have not been uploaded or validated yet.
Write each output generation under an immutable namespace. Once required renditions and manifests are complete, validate their references and switch the video's published package pointer in a small durable operation.
If progressive availability is part of the product, publish a valid initial package and later publish a new manifest generation that adds completed renditions. Never advertise an incomplete rendition simply because its first segment exists.
Retain older generations long enough for players that already loaded their manifests to finish playback. Deleting old segments immediately after changing the current pointer can break viewers midway through a video.
Rollback becomes straightforward when generations are immutable. If a new encoding has a device compatibility problem, point new playback sessions back to the previous validated package while investigating. Existing sessions may continue using the generation they already selected according to retention policy.
Keep the Playback Control Path Small
When a viewer presses play, the application checks entitlement and retrieves video metadata. It returns the appropriate manifest location, playback context and any access token needed by the delivery layer.
The player then fetches manifests and segments directly from the CDN. Application servers should not carry the sustained media stream unless a specific product requirement justifies that cost and latency.
Separate playback session creation from segment delivery. The former may need authorisation and durable business records; the latter should be highly cacheable and geographically close to the viewer.
Avoid making every segment request synchronously consult the main application database. Use a documented edge authorisation mechanism, appropriately scoped signed access or another delivery design that preserves both access control and cache efficiency.
Manifest URLs and media paths should identify the immutable package generation. This improves cache behaviour and makes playback errors reproducible: operators can identify exactly which encoding and packaging version the viewer received.
Design CDN Caching and Origin Protection
Popular segments should be served from edge caches close to viewers. Immutable segment URLs allow long cache lifetimes because an object at a given URL never changes its meaning.
Manifests may have different caching rules. A static on-demand generation can be cached strongly, while a mutable current-package pointer or live manifest requires a shorter freshness policy. Keep these layers distinct rather than assigning one cache lifetime to every object.
An origin shield or equivalent aggregation layer can reduce duplicate cache misses arriving from many edges. This is particularly useful when a newly released video creates simultaneous demand for its opening segments.
Origin protection must also handle the long tail. A large library can produce many cold requests that never become popular enough to stay cached. Measure origin request rate, byte throughput and latency by content popularity rather than relying only on an impressive global hit ratio.
If the service uses multiple CDNs, routing should consider actual viewer performance, availability and cost. Switching delivery providers is not free: cache warmth, token support, manifest URLs and player behaviour all need compatible handling.
Explain the Player's Adaptive Decision
The player estimates available throughput from recent downloads and observes its buffered playback duration. It also considers screen size, decoder capability, selected language and available renditions.
At startup, it has limited evidence about the connection. Choosing a conservative initial rendition can reduce time to first frame, after which the player can increase quality as it gathers measurements and builds buffer.
When bandwidth falls, the player should usually reduce bitrate before its buffer empties. A high-resolution picture followed by repeated stalls is often a worse experience than continuous playback at a temporarily lower quality.
Avoid rapid oscillation between neighbouring renditions. Smoothing, safety margins and switching thresholds can stabilise quality, while still allowing prompt downward adaptation when conditions deteriorate.
The server prepares compatible options; the player makes ongoing choices using its local observations. A server cannot know every change in a viewer's last-mile connection quickly enough to select one permanently correct bitrate for the whole session.
Handle Seeking and Abandoned Playback
Seeking changes the download pattern. The player may discard buffered media and request segments near a new position, creating less sequential access and more cold cache traffic than ordinary playback.
Manifests and indexes must map the requested time to valid media boundaries. The player may begin decoding before the exact requested frame and present from the appropriate point, depending on the format and access points.
Avoid prefetching too far ahead without measuring waste. Many viewers leave early or jump around, so downloading large amounts of unwatched media increases delivery cost and can compete with more useful traffic on the device.
Cancellation can stop some unnecessary transfers, but requests already served may still consume bandwidth. Measure bytes downloaded compared with watched duration to understand the practical cost of buffering and prefetch policies.
Resume playback state belongs in a separate small application record. Store a sensible progress checkpoint without writing the database for every decoded frame. Handle multiple devices and completed playback according to product rules rather than letting the latest network packet blindly overwrite a newer viewing position.
Protect Restricted Content Without Breaking Playback
Authorisation determines whether a viewer may start or continue accessing a video. Signed URLs or cookies can give the CDN a time-limited scoped grant, while protected content may also require an appropriate digital rights management and licence workflow.
These mechanisms solve different problems. URL access control limits who can fetch media through the delivery path. Encryption and licence controls govern how supported players obtain the ability to decrypt protected content. Neither is a substitute for the application's entitlement rules.
Choose token lifetimes that support realistic playback and seeking, with a renewal mechanism when needed. A token that expires halfway through a long film can cause apparently random segment failures unless the player can refresh access before it runs out.
Cache keys must not accidentally make every viewer's identical segment a separate cache object if the delivery platform can safely validate access independently. At the same time, never remove security-sensitive parameters from a cache key without understanding how authorisation is enforced.
For removals, define the revocation delay across manifests, CDN caches, tokens and active sessions. Short-lived grants can limit continued access, but content already downloaded to a device has crossed a different boundary. The operational policy should reflect the capabilities of the chosen protection system.
Recover Failed Processing and Avoid Runaway Cost
Encoding jobs can fail because of malformed sources, temporary infrastructure problems, unavailable capacity or encoder defects. Classify failures so a permanently invalid file is not retried indefinitely at significant cost.
Use bounded retries and isolate suspicious input. A repeated crash on one source should not continually take down workers processing unrelated videos. Capture enough diagnostic information to reproduce the issue while protecting source content.
Schedule work according to priority and fairness. A creator uploading thousands of hours should not starve every other creator. Separate queues or weighted scheduling can protect ordinary uploads and urgent corrections.
Autoscaling encoding workers requires awareness of startup time, accelerator availability and job duration. Queue depth alone may be insufficient because one queued job can represent a ten-second clip while another represents a ten-hour recording. Estimate remaining processing work as well as job count.
Track cost per source minute, per output generation and per watched minute. Re-encoding the entire library for a new codec is a substantial investment; prioritise content where expected future viewing and quality gains justify the processing and storage cost.
Measure Quality of Experience
Playback telemetry should include time to first frame, rebuffering duration, startup failures, selected rendition, quality switches and fatal playback errors. These are closer to the viewer's experience than origin CPU or total CDN throughput alone.
Separate network stalls from user pauses and deliberate seeking. Otherwise a session with many manual pauses can appear to have poor buffering behaviour, leading the team towards the wrong optimisation.
Break measurements down by device family, player version, region, network type, codec and package generation. A new rendition may improve average quality while failing on a particular decoder or older television model.
Correlate client events with manifest and segment delivery logs using scoped session identifiers. Avoid collecting unnecessary personal viewing information, and keep retention appropriate to the diagnostic purpose.
Combine perceptual quality assessment with real playback outcomes. A technically higher-quality encode has limited value if it increases startup delay or stalls for the audience that receives it. The objective is a useful viewing experience at an acceptable total cost.
Walk Through a Playback Session
A viewer opens a twenty-minute tutorial on a mobile connection. The application confirms entitlement and returns the current immutable package manifest. The player selects a compatible codec and a conservative initial rendition, then downloads enough initial media to begin playback.
The first few segment downloads complete comfortably faster than their playback duration. Buffer grows, and the player moves to a higher rendition at an aligned boundary. Because the new rendition describes the same timeline, the change does not require restarting the video.
The viewer then enters an area with weaker coverage. Download time increases, the throughput estimate falls and the buffer begins shrinking. The player switches down before a stall occurs, preserving continuous playback even though visual detail temporarily decreases.
After the viewer seeks to the middle of the tutorial, the player requests media near that position. Those segments may be cold at the local CDN edge, so origin protection and delivery latency become relevant even though the opening segments were served from cache.
The session emits bounded telemetry describing startup time, rendition changes, seeking and any buffering. Later analysis can distinguish a packaging failure affecting every device from a network-specific slowdown affecting this session. The immutable package identifier makes it possible to reproduce the exact media the player received.
Explain What Changes for Live Streaming
Live streaming cannot encode and validate the entire programme before anyone watches. Ingest, encoding, packaging and playback proceed continuously, and the manifest exposes a moving window of available media.
The end-to-end delay includes capture, encoding, segment production, publication, network transfer and the player's safety buffer. Reducing only one component may have little effect if the player intentionally remains several segments behind the live edge.
Low-latency protocols add mechanisms that allow players to discover and fetch smaller pieces before a traditional full segment is complete. Apple's low-latency HLS guidance describes protocol extensions for that use case. The encoder, packager, origin, CDN and player must support the intended behaviour together.
Smaller buffers reduce delay but leave less protection against network variation. A sports audience may value being close to the live action, while another broadcast may prefer fewer stalls. State the target latency and acceptable buffering tradeoff before selecting the architecture.
Live recovery also needs timeline continuity. If the active encoder fails, a replacement must resume with compatible timestamps and a valid discontinuity or switching strategy. Simply pointing the manifest at an unrelated new encoder output can break decoding or move viewers unexpectedly along the timeline.
For the on-demand design, these concerns remain outside the initial scope. Keeping that boundary explicit lets the interview explore live streaming as a deliberate extension rather than quietly assuming that an offline transcoding queue can also meet a low-latency broadcast requirement.
Before release, exercise a device and content matrix that includes unusual aspect ratios, variable frame rate sources, multiple audio languages and long videos. Test interrupted segment downloads, expired access grants, unavailable renditions and package replacement during active playback. A manifest validator catches structural errors, while real player tests reveal decoder and timing behaviour. Preserve a small library of representative problem sources as regression fixtures, with permission to use them, so fixing one packaging defect does not reintroduce another. Validate captions and audio selection as part of the same release instead of treating them as optional details discovered after viewers complain.
Summary
Adaptive video streaming connects an offline media pipeline with a highly distributed playback path. The pipeline analyses sources, encodes suitable renditions, aligns segments, packages manifests and publishes only validated generations.
The CDN serves immutable media efficiently, while the player adapts quality using its own buffer and network observations. Access control, captions, seeking, package retention and failure recovery all need to fit that core flow.
In an interview, separate encoding capacity, stored output and delivery demand, then explain the tradeoffs behind segment duration, bitrate ladders and freshness. A complete design is judged by whether viewers can start quickly and keep watching reliably, not simply by whether the original video file has been stored successfully.