You're asked to estimate outbound network bandwidth for a video-streaming service with 5 million concurrent viewers, each streaming at an average bitrate of 4 Mbps, and to state how confident you are in the resulting number. Walk through the bandwidth calculation, then explain where this kind of back-of-envelope reasoning tends to break down in the real world and what you'd do to compensate.

## Why bandwidth is the binding constraint here Bandwidth estimation follows the same core discipline as QPS and storage estimation - multiply a per-unit cost by a concurrency or rate figure - but it's worth walking through explicitly because video is the domain where bandwidth, rather than QPS or storage, is usually the binding constraint, and because it's a good vehicle for discussing where back-of-envelope reasoning as a whole starts to mislead rather than inform. ## The calculation The calculation itself is simple: outbound bandwidth = concurrent streams x bitrate per stream. With `5,000,000` concurrent viewers at `4 Mbps` average, that's `20,000,000 Mbps`, or `20 Tbps` (terabits per second), of instantaneous outbound data. Converting units carefully matters here - bandwidth is conventionally expressed in bits per second while storage is in bytes, and mixing them up by a factor of 8 is one of the most common silent errors in this kind of estimate. `20 Tbps` is a genuinely enormous number - for context, it's roughly the scale that only a handful of the largest content delivery networks and cloud backbones operate at in aggregate - which itself should prompt a sanity check: does 5 million truly simultaneous viewers at a shared moment sound right for this product, or is that itself an assumption worth interrogating (a live global sporting final might genuinely produce a number like this; a general-purpose on-demand service spreading views across time zones and content catalog would not concentrate this much simultaneous demand). ## Where the multiplication starts to mislead The reason this simple multiplication both matters and is dangerous is the same reason all back-of-envelope math is valuable and limited: it's excellent at establishing order of magnitude fast, which is exactly what's needed early in a design discussion to rule out obviously wrong architectures (a single server obviously cannot serve 20 Tbps; this must be a globally distributed, CDN-backed design), but it silently launders away every piece of real-world heterogeneity that determines whether an actual deployment survives contact with real traffic. Four specific breakdowns are worth naming explicitly. 1. **First, the average bitrate hides the real distribution**: adaptive bitrate streaming (ABR) means individual viewers sit anywhere from under 1 Mbps (mobile, poor connection, lower-resolution stream) to 15-25 Mbps+ (4K on a strong connection), and the true aggregate load depends on the actual mix of device types, network conditions, and content resolution requested at that moment - not a single averaged figure, which can be wrong in either direction depending on what's popular right now. 2. **Second, the estimate treats bandwidth as one undifferentiated pool**, when in reality traffic must be served from specific points of presence (PoPs) or CDN edge nodes near each viewer; the real engineering question isn't 'how much bandwidth in total' but 'how much bandwidth does each of dozens or hundreds of regional edges need,' and demand is never evenly distributed across those edges - a live event popular in one time zone concentrates load onto specific regional infrastructure far beyond its 'fair share' of the global total. 3. **Third, 5 million concurrent itself is not a fixed input** but a number that has its own peak-vs-average and growth dynamics - concurrency during a live event can spike sharply within a single-digit number of minutes around a kickoff or start time, a pattern flatter time-series-based provisioning can miss entirely. 4. **Fourth, the estimate says nothing about second-order effects like origin load** (even with a CDN caching most traffic, cache misses and live-encoding origin servers still need their own bandwidth and compute capacity, which scales differently from edge delivery). ## Speed against fidelity The trade-off in relying on this kind of estimate is speed versus fidelity: back-of-envelope math takes minutes and is exactly the right tool for an interview or an early design review, where the goal is agreeing on the shape of the solution (needs a CDN, needs multi-region, roughly this order of magnitude of infrastructure) - but it is the wrong tool, used alone, for actually provisioning production infrastructure, where the cost of being wrong (an outage during the exact live event the whole system was built for) is high enough to justify much more rigorous methods: - load testing against realistic traffic shapes - historical telemetry from comparable past events - staged capacity ramps with real-time monitoring during the event itself - pre-negotiated burst capacity with CDN/cloud providers ## The failure mode The failure mode of trusting the single multiplication uncritically is a genuine, recurring production incident pattern: teams that provision based on a single global aggregate number, without breaking it down by region or building in real headroom, get blindsided not by the number being wrong in total, but by its distribution being wrong - the edge serving one popular region saturates long before the 'total capacity is sufficient' spreadsheet would suggest a problem exists. A well-documented real-world case is large live-streaming events - major sports broadcasts on services like ESPN+, Hotstar (which has publicly discussed handling tens of millions of concurrent viewers during cricket finals), or Twitch during major esports events - all of which describe capacity planning as a combination of back-of-envelope sizing to set the initial architecture and infrastructure order-of-magnitude, followed by extensive load testing, regional traffic modeling, and live-event-specific pre-scaling, precisely because a single multiplication of concurrent viewers times average bitrate gets the right ballpark but is never trusted as the final provisioning number for an event where failure is highly visible and costly.