YouTube data platform — Requirements
01
Workload Model
Assumptions
1000M daily viewers→300 events/viewer/day→300B events/day
02
Traffic Math
Event derivation
Rate + bytes
Event mix
Playback heartbeats200 / viewer
Other event families100 / viewer
03
Storage Math
Kafka · hot replay log
× 604,800 sec →(7 × 24 × 60 × 60)× RF3 →
Bronze · immutable object storage
÷ 5 compression →× retention →
04
Resource Plan
INGEST→
COMPUTE+
SERVE→ 80% cache →
Benchmark inputs are interview assumptions, not claims about YouTube’s private infrastructure.
05
SLOs
Freshness ladder
Reliability
Serving
06
Interview Answer
I start with 1B daily viewers, 5 playback sessions per viewer, 600 watched seconds per session, a 15-second heartbeat, 100 other events per viewer, and a 3× peak. That produces 300 events per viewer, 300B events per day, 3.47M events/s average, and 10.42M events/s peak. The weighted 767-byte event gives 7.99 GB/s peak ingress. With stated benchmarks and 40% reserve, I provision 584 regional collectors, about 280 heartbeat partitions, 279 Flink tasks, 112 batch executors for the four-hour window, 4.83 PB of seven-day Kafka capacity at RF3 before broker adjustments, and 46 TB of compressed Bronze growth per day. I verify stream state, checkpoints, lake layers, serving QPS, and scan volume separately, then replace assumptions with load-test results.