YouTube

Assume 500 hours of video uploaded per minute. That is 720,000 uploaded hours per day. If the average video is 12 minutes, the platform receives about 2,500 new videos per minute, or about 3.6M new videos per day.

Assume an average raw upload size of 4 GB per hour after client-side compression. Raw ingest is therefore about 2.9 PB per day. After transcoding, store an ABR ladder with several video resolutions, audio tracks, thumbnails, captions, manifests, and safety copies; budget about 12 GB of encoded media per uploaded hour, or about 8.6 PB of new encoded media per day before replication overhead.

Assume 5B video starts per day, an average watch duration of 12 minutes, 4-second media segments, and an average delivered bitrate of 3 Mbps across mobile, web, and TV. That means about 60B watch minutes per day, 900B segment requests per day, and roughly 1.35 EB of video egress per day served primarily by CDN edges.

• Upload hours: 500 hours per minute times 60 minutes times 24 hours is 720,000 uploaded hours per day.
• New videos: 500 hours per minute is 30,000 uploaded minutes per minute. Dividing by a 12 minute average video length gives about 2,500 videos per minute, or 3.6M videos per day.
• Raw ingest: 720,000 hours per day times 4 GB per hour is 2.88 PB per day. Dividing by 86,400 seconds gives about 33 GB per second of average raw upload traffic before peak multipliers.
• Encoded output: 720,000 hours per day times 12 GB per hour is 8.64 PB per day for ABR renditions, audio, manifests, and thumbnails. With raw retention and storage overhead, plan for 12 to 15 PB of durable daily growth.
• Playback starts: 5B video starts per day divided by 86,400 seconds is about 57,870 starts per second. A 10x peak gives roughly 580,000 starts per second.
• Segment requests: 5B starts times 12 minutes times 60 seconds divided by 4-second segments is about 900B segment requests per day, or about 10.4M requests per second average.
• Watch time: 5B starts times 12 minutes is 60B watch minutes, or 1B watch hours per day.
• Egress: 3 Mbps for 1B watch hours is about 1.35 EB per day. Spread across a day, that is about 125 Tbps average global delivery, with peak multiples handled by CDN capacity and regional edge caches.
• View events: one heartbeat per watch minute yields 60B heartbeat events per day. Dividing by 86,400 seconds gives about 694,000 events per second before start, pause, seek, and completion events.

• videos.video_id is the primary lookup for watch pages and management.
• videos.channel_id, published_at supports channel pages and creator dashboards.
• videos.visibility, published_at helps scheduled publishing and public browsing jobs.
• media_assets.video_id, asset_type, profile finds manifests, renditions, thumbnails, and captions for a video.
• upload_sessions.upload_id supports chunk resume and idempotent finalization.
• comments_reactions.video_id, created_at supports comment pagination and recent activity.
• Search uses a separate inverted index over title, description, tags, channel name, language, safety labels, and engagement-derived ranking features.

Each video belongs to one channel and has many media assets. Playlists reference many videos in ordered lists. Comments and reactions reference a video and optionally a parent comment. Public counters on the videos row are derived summaries, not the source of truth for raw view events.

A production system usually mixes stores. Use a strongly consistent relational or distributed SQL store for video publish state, channel ownership, and playlist metadata. Use blob storage for media. Use Cassandra, Bigtable, DynamoDB, or sharded MySQL for comments and reactions partitioned by video id. Use Kafka, Pub/Sub, or Kinesis for watch events, then aggregate into Bigtable, Druid, Pinot, ClickHouse, or another analytics store. Use Elasticsearch, OpenSearch, Solr, or a custom search stack for metadata retrieval.

Large video uploads fail often because browsers close, phones move networks, and files can be several GB. The upload API should create a session before any media bytes are accepted. The session stores video id, owner, expected size, chunk size, object prefix, received ranges, checksums, state, and expiration. The client uploads chunks independently and can ask which ranges are missing after a reconnect.

Idempotency is central. A repeated chunk with the same part number, byte range, and checksum should return success. A repeated part with different bytes should return a conflict. The upload service should avoid keeping entire files on local disk; it streams chunks to blob storage and keeps only session state in a database or strongly consistent cache. Abandoned sessions are cleaned by a sweeper that deletes partial objects after expiration.

Finalization is a state transition, not a best-effort flag. The service verifies all ranges, commits the object, records the raw asset, and enqueues the transcode job exactly once using an idempotency key such as upload id. If the enqueue step fails after the raw object is committed, a reconciliation job scans complete uploads with no processing job and repairs them.

The encoding pipeline is a durable workflow. After upload completion, a job enters a queue. Workers probe the raw file for duration, resolution, codecs, audio tracks, corruption, and safety metadata. The system then chooses a rendition ladder. A common ladder includes 240p, 360p, 480p, 720p, 1080p, and higher profiles only when the source and policy allow it. Generating every possible profile wastes compute and storage.

Each rendition is segmented for adaptive streaming. HLS and DASH manifests describe available bitrates and segment URLs. The player starts with a conservative bitrate and switches up or down as bandwidth changes. This is why the platform stores many small segment objects rather than one monolithic video file for playback.

Workers should be idempotent by output path and profile. A failed 1080p encode should not invalidate a successful 360p encode. The publish decision can require a minimum playable set, such as audio plus 360p and 720p, while higher profiles continue processing. Thumbnails, preview sprites, content fingerprints, captions, and moderation scans can run as separate jobs in the same workflow.

Playback creates enormous fanout. One viral video can generate millions of segment requests per second across regions. The CDN should cache manifests, segments, thumbnails, captions, and preview sprites close to viewers. Versioned object names are better than overwriting media objects because edge caches can serve immutable assets safely.

The first viewer in a region may cause an origin fill from blob storage. Later viewers should hit the edge. Cache keys should include video id, asset version, profile, segment number, and authorization class if the video is private or rented. Public segments can use long TTLs. Private or region-restricted media can use signed URLs or signed cookies with short validity.

Origin protection matters. If a popular video is newly published, many edges may miss at once. Use request coalescing, origin shields, pre-warming for predicted hot videos, and tiered caching. The metadata service should not sit in the media-byte path; it issues or returns manifest URLs, while the CDN and blob origin serve the bytes.

Updating a videos row for every view is a classic bottleneck. With 5B starts per day and heartbeat events near 700,000 per second average, exact synchronous counters would create hot rows for popular videos and couple playback to analytics storage. Instead, the player emits view events and watch heartbeats to the engagement pipeline.

The pipeline deduplicates by viewer id or anonymous device id, video id, watch session id, IP bucket, and time window. Product rules define what counts as a view, for example minimum watch time and not obvious replay spam. Consumers batch increments by video id and time bucket, then update sharded counters or approximate sketches. Public counts can lag by seconds or minutes and may be rounded for very large numbers.

For massive videos, use counter shards such as video id plus shard number to spread writes. Periodic jobs merge shards into hourly and daily aggregates. Unique viewers and anti-spam checks can use approximate structures such as HyperLogLog and Bloom filters, plus abuse models. The watch page reads the latest materialized estimate rather than scanning raw events.

The metadata service owns videos, channels, playlists, visibility, processing state, and creator edits. This data changes far less frequently than playback segment reads but must be correct. Watch pages can cache public metadata by video id, while creator dashboards may require fresher reads and authorization checks.

Comments and likes are social workloads with different access patterns. Likes need per-user idempotency so one user cannot like a video repeatedly. Comments need pagination, moderation state, spam detection, replies, ranking, and deletion. Store comment timelines partitioned by video id and time or by comment id ranges for extremely hot videos. Keep comment writes out of the playback byte path.

Search consumes metadata updates, captions, channel authority, freshness, and engagement signals. Recommendation systems consume watch history, subscriptions, likes, comments, skips, dwell time, freshness, and embeddings. Search favors query relevance and precision; recommendations favor personalized ranking, diversity, freshness, and long-term satisfaction. Both can be eventually consistent and should degrade independently from playback.

A watch page is not one request. It may call metadata, player configuration, ads, comments, recommendations, captions, view logging, and then many segment URLs. The system should keep the critical path small: return enough metadata and a manifest quickly, let the CDN serve media bytes, and load comments or recommendations asynchronously if needed.

Fanout control is essential on home pages and related-video panels. Instead of calculating everything online, precompute candidate sets, cache ranked feeds for short windows, and use lightweight online re-ranking. For anonymous or cold-start users, use geography, language, trending videos, freshness, and device class. For logged-in users, blend subscriptions, watch history, topic embeddings, and exploration.

When non-critical services fail, playback should still work. If recommendations are unavailable, return trending or subscription fallbacks. If comments are unavailable, hide or delay comments. If view logging is delayed, buffer and retry. The viewer should not experience a playback failure because a social or analytics dependency is unhealthy.

Alternative one is a simpler file-hosting design where uploaded videos are stored as one object and streamed directly from origin. It is easier to build but fails on global latency, adaptive quality, origin load, and cost.

Alternative two is a synchronous processing design where the upload request waits for transcoding. This gives immediate success or failure but is unacceptable for long videos because requests time out, retries duplicate work, and creators wait too long.

Alternative three is an edge-heavy design that pushes popular manifests and metadata to CDN workers. This improves latency for public videos but complicates authorization, comments, freshness, and debugging. It is best as an optimization after the core system is correct.

Do not use a full YouTube-style architecture for a small internal training portal or a product with a few thousand videos. A managed video platform, object storage, CDN, and a simple metadata database are enough until upload volume, playback egress, personalization, or moderation needs justify custom media processing infrastructure.