A video service has 5 million concurrent viewers at peak, streaming an average 3 Mbps. Estimate peak egress bandwidth and daily data transfer, and say what that implies for architecture.
Key points
- Peak egress, 5M × 3 Mbps = 15 Tbps (terabits per second)In plain words: Five million people each pulling three megabits at once adds up to fifteen million megabits every second
- That is far beyond any single datacenter's uplink, so delivery must come from a CDN or ISP-embedded cachesIn plain words: No single building has a pipe that wide, so the video has to be served from many places near the viewers
- Daily transfer, assume 2 hours average viewing per DAU, e.g. 50M DAU × 2 h × 3 Mbps ≈ 135 PB per dayIn plain words: Multiply viewers by hours watched by the stream rate to get a day's total, which here lands above a hundred petabytes
- Adaptive bitrate (multiple renditions per title) multiplies storage, not egress, each viewer pulls one renditionIn plain words: Keeping several quality levels means more files to store, but each viewer still downloads only one of them
- Egress cost dominates, so caching hit rate at the edge is the key business metricIn plain words: Sending data out is the biggest bill, so the share of requests answered by nearby copies matters most
Model answer
Video is the workload where bandwidth, not storage or QPS, decides the architecture.
Peak egress 5 × 10^6 viewers × 3 Mbps = 15 × 10^6 Mbps = 15 Tbps.
For scale: a large datacenter might have a few Tbps of total internet uplink. You cannot serve this from one place, or from ten. It has to be served from hundreds of edge locations, ideally from caches sitting inside ISP networks so the traffic never crosses a paid transit link. This is why Netflix built Open Connect and why YouTube runs caches at ISPs.
Daily transfer Assume 50 million DAU watching 2 hours each. 3 Mbps × 3,600 s = 10.8 Gb per hour ≈ 1.35 GB/hour. 50 × 10^6 × 2 h × 1.35 GB ≈ 135 PB/day, roughly 4 EB per month.
At cloud egress list prices (cents per GB) that is tens of millions of dollars per month, so every point of CDN hit rate is worth real money.
Origin load If the edge serves 98% of bytes, origin egress at peak is 2% × 15 Tbps = 300 Gbps, still substantial, which is why a mid-tier (origin shield) sits between edge and origin to collapse misses.
Storage vs egress Adaptive bitrate requires encoding every title into 6–10 renditions (240p through 4K). That multiplies storage roughly 3–4× relative to the top rendition, but each viewer downloads only one rendition at a time, so egress is unchanged. Storage for a 10,000-title catalog at ~20 GB per title per rendition set is ~200 TB, trivial next to egress.
Live vs on-demand On-demand has a long tail but popular titles cache well. Live streams are perfectly cacheable (everyone wants the same 4-second segment at the same time) but the segments are new every few seconds, so the edge must fetch each one once and fan it out; origin load scales with the number of PoPs, not viewers.
Say the Tbps number, say "this cannot come from a datacenter", and the rest of the design follows.
Likely follow-ups
- How much origin bandwidth do you need if the CDN hit rate is 98%?
- How do live streams change the caching story compared with on-demand?