Video is the single most demanding workload in all of computing. YouTube alone accounts for roughly 15% of all internet downstream traffic globally, placing it alongside Netflix as the largest consumer of bandwidth on the planet. Users upload over 500 hours of video every single minute, which translates to roughly 720,000 hours of new content every day. On the consumption side, viewers watch over 1 billion hours of video per day across YouTube. These numbers make a video platform one of the most challenging systems to design at scale, touching every layer of the stack from storage to networking to compute.

To put the storage challenge in perspective, a single hour of raw 4K video at 60fps produces approximately 300-500 GB of data before compression. After encoding at reasonable quality, one hour of 4K content still requires roughly 7-10 GB per resolution. When you factor in the codec ladder (encoding each video into multiple resolutions and bitrates for adaptive streaming), a single one-hour upload might produce 20-40 GB of transcoded output across all variants. At 500 hours uploaded per minute, the platform must ingest and process roughly 150-300 TB of raw video per day and produce 1-3 PB of transcoded output daily.

The compute requirements are equally staggering. Transcoding a single minute of video from raw upload to the full codec ladder (6-8 resolution/bitrate variants) takes approximately 2-10 minutes of CPU time depending on codec and hardware acceleration. At 500 hours uploaded per minute, you need thousands of transcoding workers running in parallel just to keep up with the ingest rate. During viral events or live streaming spikes, this demand can surge 5-10x, requiring elastic compute that can scale up within minutes.

What makes video platform design a favorite system design interview question is that it forces candidates to reason across every dimension of distributed systems simultaneously. You cannot design a video platform without understanding object storage, message queues, worker pools, CDNs, streaming protocols, database design, and cost optimization. It is a true end-to-end system design problem that separates candidates who can reason about system interactions from those who only understand individual components.

The system must handle an enormous asymmetry between upload and viewing patterns. A typical video platform has a read-to-write ratio of roughly 200:1 to 1000:1 in terms of bandwidth. A single popular video might be uploaded once but viewed millions of times. This asymmetry fundamentally shapes the architecture: the upload path can be somewhat slow and asynchronous, but the viewing path must be blazing fast, globally distributed, and highly available. The upload pipeline is a background processing system; the viewing pipeline is a real-time content delivery network.

Before drawing architecture diagrams, you must establish the requirements and run the numbers. Capacity estimation is not just a formality in video platform design — the numbers are so large that they directly determine which architectural patterns are feasible. A wrong assumption about upload volume or storage requirements can lead to an architecture that collapses under real load.

Now let us work through the back-of-the-envelope numbers. These calculations will drive every architectural decision in the sections that follow.

These numbers make it clear that the three pillars of video platform economics are bandwidth (CDN costs), storage (object store lifecycle management), and compute (transcoding fleet). Every architectural decision in the following sections is ultimately about optimizing one of these three cost centers while maintaining user experience.

The upload pipeline is the entry point for all content entering the platform. Despite being asynchronous (users do not expect their video to be available instantly), the upload path must be robust, resumable, and capable of handling files that range from 10 MB phone clips to 100+ GB professional 4K productions. A dropped or corrupted upload wastes user time, bandwidth, and trust.

The upload flow begins at the client. The client application (web, mobile, or API) splits the video file into chunks (typically 5-10 MB each) and uploads them in parallel over HTTPS. Chunked upload is essential for large files because it enables resumability: if the network drops during a 50 GB upload, the client can resume from the last successful chunk rather than restarting from zero. The upload service reassembles the chunks in the correct order and writes the complete file to object storage.

graph LR
    A["Client App"] -->|"Chunked Upload<br/>HTTPS"| B["Upload Service<br/>(API Gateway)"]
    B -->|"Reassemble & Write"| C["Object Storage<br/>(Raw Video)"]
    B -->|"Create Record"| D["Metadata DB<br/>(PostgreSQL)"]
    C -->|"Upload Complete Event"| E["Message Queue<br/>(Kafka)"]
    E -->|"Dequeue"| F["Transcoding<br/>Orchestrator"]
    F -->|"Spawn Workers"| G["Transcoding<br/>Worker Pool"]
    G -->|"Write Variants"| H["Object Storage<br/>(Transcoded)"]
    G -->|"Update Status"| D
    H -->|"Propagate to CDN"| I["CDN Edge<br/>Caches"]

    style A fill:#e1f5fe
    style C fill:#fff3e0
    style H fill:#fff3e0
    style E fill:#f3e5f5
    style I fill:#e8f5e9

The upload service sits behind an API gateway and handles authentication, rate limiting, and file validation. Before accepting the upload, it verifies the user is authenticated, checks upload quotas (free users might be limited to 15-minute videos, premium users to 12 hours), validates the file header to confirm it is a supported video container format, and reserves a unique video ID. The service then orchestrates the chunked upload protocol, tracking which chunks have been received and requesting retransmission of any missing or corrupted chunks.

Resumable uploads are a non-negotiable requirement. The Google Upload Protocol (used by YouTube) and the TUS protocol are industry standards for resumable uploads. The client tracks which chunks have been successfully uploaded (confirmed by the storage service), and on network failure, it queries the server for the upload state and resumes from the last confirmed chunk offset. For very large files (50+ GB), uploads may span hours or even be paused and resumed across sessions.

Error handling in the upload pipeline must be thorough. If the assembled file fails validation (corrupted container, unsupported codec, zero-duration), the system must notify the user with a clear error message and clean up the partial upload from object storage. If the video passes validation but transcoding later fails, the raw file should be retained for a retry window (typically 72 hours) before garbage collection deletes it. The metadata record tracks the video through every state: UPLOADING, VALIDATING, PROCESSING, READY, FAILED.

Transcoding is the computational heart of a video platform. It converts the raw uploaded video — which may be in any format, resolution, or codec — into a standardized set of output variants optimized for streaming. Each variant targets a specific combination of resolution, bitrate, and codec, forming what is known as the codec ladder or encoding ladder. The goal is to produce a version of the video for every combination of device capability and network condition a viewer might have.

A typical codec ladder for a YouTube-scale platform includes 6-8 variants per video. For a 1080p upload, the output ladder might include: 2160p (4K upscale only if source is 4K), 1080p at 4-6 Mbps, 720p at 2.5-4 Mbps, 480p at 1-2 Mbps, 360p at 0.5-1 Mbps, and 240p at 0.3-0.5 Mbps. For each resolution, the video is split into small segments (typically 2-6 seconds each) for adaptive bitrate streaming. Each segment is independently decodable, allowing the player to switch between quality levels at segment boundaries without any glitch or buffering.

The choice of codec has enormous implications for quality, bandwidth, and compute cost. H.264 (AVC) is the universal baseline: every device supports it, encoding is fast, but compression efficiency is the worst of the modern codecs. H.265 (HEVC) offers 30-40% better compression than H.264 at equivalent quality, but licensing costs are complex and fragmented (multiple patent pools), and not all browsers support it natively. VP9 (developed by Google) provides similar compression gains to H.265 without licensing fees and is the primary codec used by YouTube. AV1 (developed by the Alliance for Open Media, including Google, Netflix, Meta, and Amazon) achieves 30-50% better compression than H.264 and is royalty-free, but encoding is 10-100x slower than H.264, making it extremely compute-expensive.

The transcoding architecture must handle massive parallelism. Rather than processing each video serially, the system uses a DAG (Directed Acyclic Graph) task pipeline. When a new video arrives for transcoding, the orchestrator breaks it into a graph of dependent tasks: first, extract audio and perform audio transcoding; in parallel, probe the video to determine source resolution and codec; then, for each target resolution, create an encoding task that depends on the probe result. Each encoding task is further parallelized by splitting the video into temporal chunks (e.g., 10-second segments) and encoding them in parallel across multiple workers, then concatenating the results.

graph TD
    A["VIDEO_UPLOADED Event"] --> B["Transcoding Orchestrator"]
    B --> C["Probe: Extract Source<br/>Metadata"]
    B --> D["Extract & Transcode<br/>Audio (AAC)"]
    C --> E{"Source Resolution<br/>≥ 1080p?"}
    E -->|Yes| F["Encode 1080p<br/>(H.264 + AV1)"]
    E -->|Yes| G["Encode 720p<br/>(H.264)"]
    E -->|Yes| H["Encode 480p<br/>(H.264)"]
    E -->|No| G
    E -->|No| H
    E -->|Always| I["Encode 360p<br/>(H.264)"]
    E -->|Always| J["Encode 240p<br/>(H.264)"]
    F --> K["Generate Segments<br/>& Manifest"]
    G --> K
    H --> K
    I --> K
    J --> K
    D --> K
    K --> L["Thumbnail<br/>Extraction"]
    L --> M["Mark Video READY<br/>Update Metadata"]

    style A fill:#f3e5f5
    style B fill:#e1f5fe
    style M fill:#e8f5e9

FFmpeg is the industry-standard tool at the core of nearly every transcoding pipeline. It handles container parsing, codec decoding/encoding, resolution scaling, audio extraction, and segment packaging. Production systems wrap FFmpeg in a worker service that receives tasks from the message queue, executes the FFmpeg command, uploads the output to object storage, and reports completion back to the orchestrator. Hardware acceleration via NVIDIA GPUs (NVENC) or Intel Quick Sync can speed up H.264/H.265 encoding by 5-10x compared to CPU-only encoding.

The orchestrator tracks each video through the transcoding DAG and handles failures gracefully. If a single encoding task fails (worker crash, spot instance preemption), the orchestrator retries that specific task on a new worker without restarting the entire pipeline. Once all variants for a video are complete, the orchestrator triggers manifest generation (creating the HLS/DASH playlist files that reference all segments across all quality levels), updates the metadata database to mark the video as READY, and the video becomes available for viewing.

The CDN is the delivery backbone of a video platform. Without it, every viewer request would travel back to the origin data center, creating unbearable latency for distant users and overwhelming the origin with traffic that no single datacenter could handle. A well-designed CDN for video serves over 90% of requests from edge caches located physically close to the viewer, reducing round-trip latency to under 20ms and shielding the origin from the vast majority of traffic.

A video CDN operates as a hierarchical caching system with three tiers. The first tier is the edge Points of Presence (POPs), deployed in hundreds of locations worldwide, often co-located in ISP datacenters or Internet Exchange Points (IXPs). These are the caches closest to the viewer and handle the vast majority of requests. The second tier is the regional shield (also called mid-tier cache or origin shield), which sits between the edge POPs and the origin. When an edge POP has a cache miss, it requests the content from the regional shield rather than going directly to the origin. This aggregates demand from multiple edge POPs in the same region and dramatically reduces origin load. The third tier is the origin storage, the authoritative source of all transcoded video segments.

graph TD
    A["Viewer in Tokyo"] -->|"Request Segment"| B["Edge POP<br/>Tokyo"]
    C["Viewer in Osaka"] -->|"Request Segment"| D["Edge POP<br/>Osaka"]
    B -->|"Cache Miss"| E["Regional Shield<br/>Asia-Pacific"]
    D -->|"Cache Miss"| E
    E -->|"Cache Miss"| F["Origin Storage<br/>(us-east-1)"]
    F -->|"Segment Data"| E
    E -->|"Cache & Forward"| B
    E -->|"Cache & Forward"| D
    B -->|"Stream"| A
    D -->|"Stream"| C

    G["Viewer in London"] -->|"Request Segment"| H["Edge POP<br/>London"]
    H -->|"Cache HIT"| G

    style A fill:#e1f5fe
    style C fill:#e1f5fe
    style G fill:#e1f5fe
    style B fill:#e8f5e9
    style D fill:#e8f5e9
    style H fill:#e8f5e9
    style E fill:#fff3e0
    style F fill:#fce4ec

Cache-fill optimization is one of the most important aspects of video CDN design. When a new video goes viral, hundreds of edge POPs worldwide will simultaneously experience cache misses for the same segments. Without coordination, they would all send requests to the origin simultaneously, creating a thundering herd that could overwhelm origin bandwidth. The regional shield solves this by collapsing duplicate requests: if the shield is already fetching segment X from origin, additional requests for segment X from other edge POPs in the region wait for the first fetch to complete and then receive the cached copy. This is called request collapsing or request coalescing.

Geographic routing determines which edge POP serves each viewer. DNS-based routing (GeoDNS) resolves the CDN hostname to the IP address of the nearest POP based on the viewer's DNS resolver location. Anycast routing announces the same IP address from multiple POPs and relies on BGP routing to direct traffic to the closest one. In practice, large video platforms use a combination: GeoDNS for initial connection routing and anycast for failover. The routing decision also considers POP health and load: if the nearest POP is at capacity or experiencing issues, traffic is redirected to the next closest healthy POP.

The economics of video CDN are dominated by bandwidth costs. At YouTube scale, building your own CDN (private backbone, ISP-embedded caches) is far cheaper than using commercial CDN providers. For smaller platforms, a multi-CDN strategy (using Cloudflare, Akamai, and Fastly simultaneously) provides geographic redundancy and cost optimization through competitive pricing. The CDN selection layer routes each viewer request to the CDN with the best combination of cost and performance for that specific geographic region.

Adaptive Bitrate (ABR) streaming is the technology that allows a video player to seamlessly switch between quality levels in real time based on the viewer's network conditions. Without ABR, a viewer on a variable mobile connection would experience constant buffering as the player attempts to download segments at a fixed bitrate that exceeds available bandwidth. ABR solves this by breaking the video into small segments and allowing the player to choose a different quality level for each segment independently.

The two dominant ABR protocols are HLS (HTTP Live Streaming, developed by Apple) and DASH (Dynamic Adaptive Streaming over HTTP, an open ISO standard). Both work on the same fundamental principle: the server provides a manifest file that lists all available quality levels and the URLs of every segment at each quality level. The client player downloads the manifest, monitors network conditions, and selects the appropriate quality for each subsequent segment. The key difference is format: HLS uses M3U8 playlist files and MPEG-TS or fMP4 segments, while DASH uses an XML-based MPD (Media Presentation Description) file and fMP4 segments. In practice, modern platforms produce both HLS and DASH manifests from the same underlying fMP4 segments.

The manifest file is the control plane of adaptive streaming. A master HLS manifest (multi-variant playlist) lists all available quality levels with their resolution, bitrate, and codec. For each quality level, there is a media playlist that lists the URLs of individual segments. When the player starts, it downloads the master manifest, selects an initial quality level (often the lowest for fast startup), and begins downloading segments. As it accumulates data on available bandwidth, it switches to higher quality levels.

The ABR algorithm in the client player is where the intelligence lives. The algorithm must balance three competing objectives: maximize video quality (use the highest bitrate the network can sustain), minimize rebuffering (never let the playback buffer run dry), and minimize quality oscillation (avoid rapidly switching between low and high quality, which is visually distracting). The most common approach is buffer-based ABR: the algorithm maintains a target buffer level (typically 30-60 seconds of video) and adjusts quality based on how full the buffer is. When the buffer is high (well above target), the algorithm selects higher quality. When the buffer is draining (below target), it switches to lower quality aggressively to prevent rebuffering.

Segment duration is a critical design parameter with cascading effects. Shorter segments (2 seconds) enable faster quality switching and lower latency for live streams, but they increase the number of HTTP requests (higher overhead), increase manifest file size, and slightly reduce encoding efficiency (each segment must start with a keyframe, and shorter segments have a higher percentage of keyframes). Longer segments (6-10 seconds) improve encoding efficiency and reduce request overhead but make quality switching sluggish and increase live-stream latency. The industry consensus for on-demand video is 4-6 second segments, with 2-4 seconds for live streams where latency matters.

In an interview, discussing ABR demonstrates understanding of client-server interaction, the tension between quality and reliability, and how user experience metrics (rebuffer rate, startup time, average quality) drive system design decisions. The best candidates discuss how ABR algorithms are tuned using A/B testing with real viewer experience metrics.

Every video on the platform is more than just a media file. It is accompanied by a rich metadata record that powers search, recommendations, content moderation, and the viewing experience. The metadata system is the connective tissue of the platform, linking the video content in object storage to the user-facing features in the application. Designing this layer correctly is essential because metadata operations happen at much higher frequency than video operations: every page load, every search query, and every recommendation request reads metadata, while video files are written once and read through the CDN.

The metadata record for each video includes core fields (video_id, owner_id, title, description, tags, category, upload_timestamp, duration, status), technical fields (source_resolution, source_codec, source_framerate, transcoded_variants with paths to each quality level in object storage), engagement fields (view_count, like_count, comment_count, share_count), and derived fields (thumbnail_urls, auto_generated_captions, content_fingerprint_hash). This record lives in a relational database (PostgreSQL) for transactional integrity, with denormalized copies in Elasticsearch for full-text search and in Redis for low-latency serving.

Thumbnail generation deserves special attention because thumbnails are the primary visual element driving click-through rates. The system generates thumbnails at multiple stages. During transcoding, the pipeline extracts frames at regular intervals (every 5-10 seconds) and selects 3-5 candidate thumbnails based on visual quality heuristics: prefer frames with good contrast, clear subjects, and no motion blur. These candidates are stored in object storage and presented to the creator for selection. Advanced systems use ML models trained on click-through rate data to rank thumbnails by predicted engagement, automatically selecting the thumbnail most likely to attract views.

Search is powered by Elasticsearch indexing the video metadata. When a user searches for "how to cook pasta", the query hits an Elasticsearch cluster that matches against the title, description, tags, and auto-generated captions (produced by speech-to-text during transcoding). Results are ranked by a combination of text relevance (BM25 score), engagement signals (videos with higher view counts and engagement rates rank higher), recency (newer videos get a freshness boost), and creator authority (channels with more subscribers rank higher for their topic area). The search pipeline also handles query understanding: spelling correction, query expansion (adding synonyms), and intent classification (is the user looking for a tutorial, a review, or entertainment?).

Engagement counters (view count, like count) present a classic distributed systems challenge. View counts must be accurate enough for creator analytics and monetization but are updated at extreme rates (a viral video may receive thousands of views per second). The solution is a write-behind pattern: increment a per-video counter in Redis (or an in-memory counter on the application server), and flush the accumulated count to PostgreSQL periodically (every 30-60 seconds) in a batch write. This reduces database write load by orders of magnitude while keeping the displayed count accurate to within a minute of real-time.

Content moderation is both a legal requirement and an existential concern for any video platform. Without effective moderation, the platform becomes a vector for copyright infringement, hate speech, child exploitation, terrorism content, and misinformation. Governments worldwide have enacted laws requiring platforms to remove certain categories of content within hours of notification, with severe penalties for non-compliance. At the same time, over-moderation (removing legitimate content) alienates creators and harms free expression. The moderation system must balance accuracy, speed, and fairness at massive scale.

Copyright detection is the most technically mature aspect of content moderation. YouTube's Content ID system is the gold standard: it maintains a database of reference files (audio and video fingerprints) submitted by copyright holders. Every uploaded video is fingerprinted and compared against this reference database. If a match is found, the copyright holder's policy is applied automatically: block the video, monetize it (run ads and share revenue with the rights holder), or track its viewership. Content ID processes over 500 hours of video per minute and makes a match decision within the transcoding pipeline, before the video becomes publicly available.

graph TD
    A["New Video Upload"] --> B["Transcoding Pipeline"]
    B --> C["Content Fingerprinting<br/>(Audio + Visual Hash)"]
    C --> D{"Match in Copyright<br/>Reference DB?"}
    D -->|"Match Found"| E{"Copyright Holder<br/>Policy?"}
    D -->|"No Match"| F["Automated Safety<br/>Scanning (ML)"]
    E -->|"Block"| G["Video Blocked<br/>Creator Notified"]
    E -->|"Monetize"| H["Video Published<br/>Ads Enabled for Rights Holder"]
    E -->|"Track"| I["Video Published<br/>Analytics Shared"]
    F --> J{"Safety Flags<br/>Detected?"}
    J -->|"High Confidence Violation"| K["Auto-Remove<br/>+ Creator Strike"]
    J -->|"Low Confidence / Edge Case"| L["Human Review Queue"]
    J -->|"Clean"| M["Video Published"]
    L --> N{"Human Reviewer<br/>Decision"}
    N -->|"Violation Confirmed"| K
    N -->|"False Positive"| M

    style G fill:#fce4ec
    style K fill:#fce4ec
    style M fill:#e8f5e9
    style H fill:#fff3e0
    style L fill:#fff9c4

Audio fingerprinting works by extracting a compact perceptual hash from the audio track. The algorithm analyzes spectral features (frequency components over time) and produces a fingerprint that is robust to common transformations: re-encoding, volume changes, slight pitch shifts, and even background noise. The reference database stores fingerprints for millions of songs, movies, TV shows, and other copyrighted content. The matching algorithm compares the upload's fingerprint against the reference database using locality-sensitive hashing (LSH) to find approximate nearest neighbors efficiently, even at the scale of millions of reference tracks.

Visual fingerprinting complements audio matching by analyzing the video frames themselves. It computes perceptual hashes of keyframes that are invariant to resolution changes, color adjustments, cropping, and mild geometric transformations. This catches cases where the audio is replaced or muted to evade audio fingerprinting. The combination of audio and visual fingerprinting catches over 98% of exact and near-exact copies of copyrighted content.

The human review pipeline handles the cases where automated systems are not confident. Reviewers are presented with flagged content alongside the ML confidence score and the reason for flagging. They make a binary decision (violation/not-violation) with a category label. Reviewer decisions are used as training data to improve the ML models over time. The human review queue must be prioritized: child safety content is reviewed within 1 hour, terrorist content within 4 hours, and general policy violations within 24 hours. Large platforms employ thousands of content reviewers, often through third-party contractors, with strict guidelines for reviewer well-being (mandatory breaks, counseling access) given the disturbing nature of much flagged content.

Appeals and creator communication complete the moderation system. Creators whose content is removed must be able to appeal the decision, understand why it was removed, and receive a timely response. A creator who receives three copyright strikes within 90 days has their channel terminated. This strike system, while imperfect, provides a framework for proportional enforcement. The appeals process should include both automated re-review (re-running the ML classifier with a lower threshold) and human escalation for disputed cases.

At video platform scale, cost optimization is not a nice-to-have — it is an existential requirement. YouTube reportedly operates at near break-even despite generating over $30 billion in annual revenue, because the infrastructure costs of storing, transcoding, and delivering billions of hours of video are staggering. Every architectural decision must be evaluated through the lens of cost per hour of video stored, transcoded, and delivered.

Storage costs are managed through a tiered lifecycle policy. Not all videos are equal: the top 1% of videos by view count generate roughly 80% of all views (power-law distribution). Yet the long tail of rarely-watched videos accounts for the vast majority of storage volume. The solution is to move videos between storage tiers based on access frequency. Hot storage (SSD-backed or high-IOPS object storage) holds videos with recent views (last 30 days). Warm storage (standard object storage like S3 Standard) holds videos with occasional views (30-180 days since last view). Cold storage (S3 Glacier, S3 Glacier Deep Archive) holds videos that have not been viewed in over 6 months. The transition between tiers is automatic, driven by a lifecycle policy that monitors per-video access patterns.

The cost difference between tiers is enormous: hot storage costs roughly 23x more than deep archive per GB. For a platform storing 1 exabyte of video, moving 30% of content from hot to cold storage saves approximately $5-6 million per month. The key challenge is predicting which videos will be accessed. A video dormant for a year might suddenly go viral due to a cultural event or social media trend. The system must handle retrieval from cold storage gracefully: when a viewer requests a cold-stored video, the system initiates an asynchronous retrieval, serves a "video loading" message, and the video becomes playable within minutes (for Glacier Instant) to hours (for Deep Archive). Simultaneously, the video is promoted back to warm or hot storage based on the access pattern.

Transcoding compute costs are the second-largest expense. The key optimization is using spot instances (AWS) or preemptible VMs (GCP) for the transcoding worker fleet. Spot instances offer 60-90% cost savings compared to on-demand pricing, with the trade-off that they can be terminated with 2 minutes notice when cloud provider needs the capacity. Transcoding workloads are ideal for spot instances because they are embarrassingly parallel, stateless, and fault-tolerant. If a spot instance is reclaimed while encoding a segment, the orchestrator simply re-queues that segment to another worker. The worker writes completed segments to object storage incrementally, so no work is lost beyond the current segment in progress.

Monitoring and attribution are essential for cost optimization. The system must track cost per video, cost per view, and cost per creator. This enables business decisions like: which creators generate positive unit economics? Which content categories are most expensive to serve? Are there videos consuming disproportionate resources (very long, very high resolution) that should be subject to different upload policies? Cost attribution data feeds into capacity planning, pricing decisions, and the design of creator incentive programs.