Lesson 3 of 15
41. Design Live Streaming at Scale (Live Cricket)

41.2 How big is this, really?

3 min read+10 XP

Step 2: Estimates (5 minutes)

Assume an average of 2 Mbit/s per viewer, 4-second segments, about 6 renditions, 10 shield sites, 200 CDN locations, and 50,000 active sessions per API server.

WhatWorkingResult
Egress25 million × 2 Mbit/s≈ 50 Tbit/s
Segment requests25 million ÷ 4 s≈ 6.25 million a second (plus playlist refreshes)
Requests reaching the origin per new segment6 renditions × 10 shields (with request collapsing)≈ 60
Score polls25 million ÷ every 10 s≈ 2.5 million a second at the CDN
Score requests reaching our servers200 locations ÷ 2 s cache TTL≈ 100 a second
API servers at peak25 million × 1.3 ÷ 50,000≈ 650 (vs ~100 needed for 5 million)

What the numbers say, out loud:

  • "The video itself is a CDN problem: 50 Tbit/s and millions of identical requests per second, which edges, ISP caches and shields absorb. The origin sees only dozens of requests per segment."
  • "The API tier is the real risk: sign-in, entitlement checks, ads and the home page are dynamic, so they don't cache well, and they spike when millions open the app at once."
  • "Capacity must be in place before the spike, because a 6x jump in 10 minutes is faster than servers can boot and warm up."

Interviewer pushback:

  • "Why not one global origin?" → The origin barely matters for load thanks to shields, but it matters for availability: run redundant encoders and origins in two regions with automatic switchover, so one failure doesn't stop the match.

Memory code: "Video is a CDN problem; the API tier is your problem."