How YouTube Handles 500M Daily Video Plays: Inside Its Scalable Architecture

Overview

YouTube is blocked in mainland China and requires a VPN to access; this note sets the context.

Globally, YouTube ranks second only to its parent Google, serving over 500 million video plays per day with each user watching 10‑15 videos on average.

Despite its massive traffic, the service is maintained by a surprisingly small team.

Basic Platform

Apache

Python

Linux (SuSe)

MySQL

psyco – a dynamic Python‑to‑C compiler

lighttpd (later replaced Apache for video delivery)

Status

Supports >5 × 10⁸ video clicks per day

Founded by Chen Shijun (born 1978) in February 2005

Reached 30 million daily clicks in March 2006

Reached 100 million daily clicks in July 2006

Reached 500 million+ daily clicks in March 2016

Team (circa 2010): 2 sysadmins, 2 scalability architects, 2 software engineers, 2 network engineers, 1 DBA

Web Server

NetScaler for load balancing and static content caching

mod_fast_cgi to run Apache

Python application server for request routing

Application servers interact with multiple databases and other data sources to generate HTML

Horizontal scaling by adding more machines at the web layer

Python code is rarely the performance bottleneck; most latency resides in RPC calls

Python enables rapid, flexible development and deployment

Typical page response time < 100 ms

psyco used to accelerate hot loops

CPU‑intensive tasks (e.g., encryption) off‑loaded to C extensions

Pre‑generated and cached HTML for expensive blocks

Row‑level caching in the database

Full‑object caching of Python objects (similar to PHP opcode or Java bytecode)

Pre‑computed values cached in memory and served via a proxy

Video Service

Cost includes bandwidth, hardware, and power consumption

Each video is served by a small cluster of machines

More disks improve storage speed

High availability and disaster recovery: failure of one machine is handled by others

Online backup

Lighttpd replaced Apache for video delivery because Apache’s overhead was too high. It uses epoll, multi‑process handling, and later transitioned to Nginx (YouTubeFrontEnd).

Key Points of Video Service Architecture

Keep the design simple and low‑cost

Maintain a simple network topology with minimal routing between content and users

Use commodity hardware; expensive hardware is hard to support

Build on Linux and common tools

Optimize random I/O (SATA tweaks)

Thumbnail Service

Process thumbnails efficiently

Four thumbnails are generated per video, so thumbnail traffic exceeds video traffic

Thumbnails are stored on a few machines

Challenges include massive OS‑level disk seeks, inode and page‑cache pressure, and large directory limits (Ext3 → multi‑level structures)

High request rates cause Apache to perform poorly; squid was added as a front‑end cache but eventually failed under load

lighttpd’s single‑threaded model caused bottlenecks; multi‑process caching was required

Restarting a machine can take 6‑10 hours to rebuild caches

Database

Early stage:

MySQL stores metadata (users, tags, video descriptions, comments)

RAID‑10 array for storage

Evolution from a single server → master/slave → partitioned → hash‑sharded architecture

Master is multi‑threaded on a large machine; slaves are single‑threaded, leading to slower backups

Cache invalidation and slow I/O cause backup latency

Additional hardware was purchased to improve write performance

YouTube split data into two clusters: one for video view data, another for other business logic

Later stage:

Database sharding distributes users across shards

Read/write spreading improves scalability

Better cache placement reduces I/O, cutting hardware needs by ~30 %

Backup latency reduced to near zero

Current architecture allows arbitrary scaling of the database layer

Data‑Center Strategy

Initially relied on third‑party hosting for payment processing; later moved to colocation to gain control

Expanded to a dozen owned IDC data centers plus CDN nodes

Video content can be served from any IDC; popular videos are replicated to CDN

Video delivery speed depends more on bandwidth than latency

Image‑heavy pages suffer from loading delays; BigTable is used to store images across data centers and serve the nearest copy

Conclusion

Innovate quickly but plan for long‑term solutions

Prioritize core services and allocate resources accordingly

Focus on simplicity; iterate architecture based on observed bottlenecks

Shard to isolate storage, CPU, memory, and I/O loads and improve write performance

Continuous iteration across software (DB, cache), OS (disk I/O), and hardware (memory, RAID) is essential

The architecture described above underpins YouTube’s massive traffic; the article invites readers to share additional insights.