Bandwidth Estimation
Bandwidth estimation computes how much network egress the system produces per second: QPS × payload size, converted from bytes/sec to Gbps (1 Gbps = 10^9 bits/sec = 125 MB/sec). The estimate determines whether the system needs a CDN, multiple regions, or peer-to-peer distribution. Bandwidth is often the dominant constraint in media-heavy systems — a single origin server cannot physically serve 100 Gbps, and even 10 Gbps is rare. Forgetting to convert bytes to bits (8x error) is the most common bandwidth-estimation mistake.
Foundational.
How it works
Bandwidth estimation computes the network egress rate the system produces: how many bits per second flow out to users. The base formula:
Bandwidth (bytes/sec) = QPS × payload_size_bytes
Bandwidth (Gbps) = bytes/sec × 8 / 10^9The crucial conversion: 1 Gbps = 10^9 bits/sec = 125 MB/sec. Note the bits, not bytes — 8 bits per byte. The most common interview mistake is treating 1 Gbps as 1 GB/sec, which is wrong by 8x.
Example (Twitter with media):
- Read QPS = 115k average.
- Timeline payload per read = 1 KB text.
- 10% of reads include media, average 1 MB.
- Text bandwidth: 115k × 1 KB = 115 MB/s = 0.92 Gbps ≈ 1 Gbps.
- Media bandwidth: 11.5k × 1 MB = 11.5 GB/s = 92 Gbps.
- Total: ~93 Gbps (peak: × 5 ≈ 465 Gbps).
A single origin server cannot serve 93 Gbps — a typical AWS instance has a 10-25 Gbps network interface. Even 10 such instances cannot physically serve 465 Gbps peak. This is why a CDN with hundreds of edge POPs is mandatory: each POP absorbs a fraction of the load, and the origin sees only the cache misses.
The deeper insight: bandwidth is often the constraint that drives the entire architecture. For Twitter, the database write QPS (11.5k) is modest — one beefy PostgreSQL could handle it. But the bandwidth (93 Gbps) is impossible without a CDN. The architecture is bandwidth-driven, not QPS-driven. Estimating bandwidth surfaces this fact; skipping it hides it.
Units — the bandwidth-estimation killer.
Bandwidth estimation has one recurring bug: confusing bits and bytes. Memorize these conversions before any interview:
- 1 byte = 8 bits. Always.
- 1 Gbps = 10^9 bits per second = 125 MB per second. (10^9 / 8 = 125 × 10^6 bytes = 125 MB.)
- 1 GB/sec = 8 Gbps. (1 GB = 8 × 10^9 bits = 8 Gbps.)
- 1 MB/sec = 8 Mbps. (1 MB = 8 × 10^6 bits.)
The common mistakes:
- Treating 1 Gbps as 1 GB/sec — off by 8x. (1 Gbps = 0.125 GB/sec.)
- Treating 1 Mbps as 1 MB/sec — off by 8x. (1 Mbps = 0.125 MB/sec.)
- Forgetting that network speeds are in bits, storage sizes are in bytes.
The rule: network bandwidth is in bits per second (bps, Kbps, Mbps, Gbps); storage and payload sizes are in bytes (B, KB, MB, GB). To convert a payload rate to bandwidth, multiply bytes/sec by 8.
Once you internalize this, the math is straightforward: QPS × payload_size_bytes × 8 / 10^9 = bandwidth in Gbps. The hard part is not the math; it is not confusing bits and bytes.
Another conversion worth memorizing: 1 day = 86,400 seconds. So 1 GB/sec for 1 day = 86.4 TB/day. And 1 PB = 10^3 TB = 10^6 GB. Cloud egress is typically priced per GB (AWS ~$0.09/GB egress), so 1 PB egress = $90k/month. This is why bandwidth is the dominant cloud cost for media-heavy systems.
A single AWS instance has a 10-25 Gbps network interface. Above 10 Gbps sustained, no single instance can serve the traffic, and even horizontal scaling within one region hits practical limits (load balancer throughput, cross-AZ bandwidth). The only way to serve 50+ Gbps is a CDN with many edge POPs, each absorbing a fraction of the load. The CDN does not just reduce latency — it is the only physically possible way to serve the bandwidth. Estimating bandwidth is how you recognize this need before designing an architecture that physically cannot work.
Egress cost — the dominant cloud bill.
Bandwidth is not just a technical constraint; it is a cost constraint. Cloud egress (data leaving the cloud to users) is the most expensive cloud line item:
- AWS egress: ~$0.09/GB (first 10 TB free, then $0.09-0.12/GB).
- GCP egress: ~$0.085/GB (similar tiered pricing).
- Cloudflare egress: $0 (their differentiator — they don't charge for egress, only for premium features).
For a media-heavy system:
- 10 GB/sec sustained = 864 TB/day = ~$78k/day = ~$2.3M/month in AWS egress.
- 100 GB/sec sustained = ~$23M/month in AWS egress.
This is why Netflix built their own CDN (Open Connect) — at their scale, AWS egress would have cost more than their entire content budget. Cloudflare's $0 egress model exists precisely because egress is the dominant cost for media-heavy customers.
A CDN does not just absorb the bandwidth physically — it also reduces the egress cost. AWS CloudFront charges ~$0.085/GB vs S3's $0.09/GB, but more importantly, when the CDN serves a cache hit, the origin does not see the traffic — so the origin's egress cost is only on misses. At 95% CDN cache hit rate, origin egress drops 20x, and origin egress cost drops with it.
The interview lesson: always estimate bandwidth AND cost. A design that is technically feasible at 100 Gbps but costs $23M/month in egress is uneconomical. The CDN is not just a performance optimization; it is a cost optimization.
The bandwidth estimation interview step-by-step.
- Start with QPS and payload size. Read QPS × payload bytes/sec = bytes/sec.
- Convert bytes/sec to Gbps. Multiply by 8 (bytes to bits), divide by 10^9.
- Estimate peak. Multiply by 3-5x peak factor.
- Identify the architecture implication.
- < 1 Gbps: single origin server works.
- 1-10 Gbps: multiple origins + load balancer.
- 10-100 Gbps: CDN mandatory, multiple regions.
- 100+ Gbps: global CDN with hundreds of POPs (Netflix, YouTube scale).
- Estimate cost. Total bytes/sec × 86400 × $0.09/GB = daily egress cost.
- Mention the CDN as the answer to both performance and cost.
For Twitter with media:
- Average: 93 Gbps → CDN mandatory (origin cannot serve).
- Peak: 465 Gbps → global CDN with many POPs.
- Cost without CDN: ~$2.3M/month in AWS egress.
- Cost with CDN (95% hit rate): ~$115k/month in origin egress (95% reduction).
The whole exercise takes 1-2 minutes. The interviewer is testing whether you recognize that bandwidth, not QPS, is the constraint for media-heavy systems, and that the CDN is the only architecture that physically and economically works at scale.
You estimate a media-heavy system at 100 GB/sec of egress. What is this in Gbps, and what architecture does it imply?
Pick one answer.
Your system serves 50 GB/day of egress. What is the approximate AWS egress cost per month?
Pick one answer.
Why does Netflix operate its own CDN (Open Connect) rather than using AWS CloudFront, given that Netflix runs on AWS for everything else?
Pick one answer.
Engineering mental model
Mental model. Think of Bandwidth Estimation as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Bandwidth Estimation mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Bandwidth Estimation, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = bandwidth_estimation(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Example: 10,000 req/s × 200 KB response ≈ 2,000,000 KB/s ≈ 2 GB/s ≈ 16 Gbps before protocol overhead. Always separate average traffic from peak traffic.
Interactive thought experiment: Bandwidth Estimation
Change the variables below and predict what breaks first in Bandwidth Estimation. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Bandwidth Estimation, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Bandwidth Estimation. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Bandwidth Estimation?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Bandwidth Estimation, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Bandwidth Estimation, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Bandwidth Estimation: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Bandwidth Estimation. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Surfaces the bandwidth constraint that often dominates media-heavy systems.
- +Forces the byte-to-bit conversion that catches common estimation mistakes.
- +Drives the CDN decision — the only physical solution for high bandwidth.
- +Enables egress cost estimation — often the largest cloud line item.
- +Reveals when single-origin architectures are physically infeasible.
- −Easy to confuse bits and bytes (8x error) — the most common mistake.
- −Requires estimating payload sizes, which vary by 10-1000x depending on assumptions.
- −Captures steady-state, not burst spikes (which can be 10-100x average).
- −Egress pricing varies by provider and is tiered — estimates are approximate.
- −Does not account for CDN cache hit rate, which dramatically reduces origin bandwidth.
How this breaks in production
- Confusing bits and bytes — off by 8x.
- Designing single-origin architectures that physically cannot serve the bandwidth.
- Forgetting to estimate egress cost — design is uneconomical.
- Not accounting for peak (× 5x) — system collapses at peak bandwidth.
- Assuming the origin handles the full load when a CDN is required.
- Forgetting that cross-AZ and cross-region bandwidth also has costs and limits.
Don't fall into these traps
- •Treating 1 Gbps as 1 GB/sec (off by 8x).
- •Not translating bandwidth into architecture decisions (CDN, multi-region).
- •Forgetting to multiply by peak factor.
- •Not estimating egress cost at all.
- •Assuming the cloud provider's published bandwidth limits do not apply to your system.
- •Forgetting that the CDN reduces origin bandwidth by the cache hit rate (often 95%).
Real systems using this
How real systems implement this
- Netflix Open Connect — Netflix operates its own CDN with ISP-embedded appliances, precisely because AWS egress at their bandwidth scale (hundreds of Gbps sustained, petabytes per day) would cost tens of millions of dollars per month. Open Connect bypasses the per-GB egress charge by serving video from within ISP facilities.
- Cloudflare's $0 egress model — Cloudflare's competitive differentiator is $0 egress — they don't charge for bandwidth out, only for premium features and computed usage. This exists because egress is the dominant cost for media-heavy customers, and undercutting AWS on egress captures those workloads.
- YouTube / Google Video Infrastructure — YouTube serves hundreds of Gbps of video globally, distributed via Google's edge cache infrastructure (GFE / Google Front End servers at ISPs). The bandwidth is split across thousands of edge POPs; no single origin could serve it.
- AWS CloudFront + S3 origin pattern — The standard pattern for media at moderate scale: S3 origin + CloudFront CDN. The CDN absorbs 90-99% of read traffic (cache hit rate), so origin egress is small and cheap. At extreme scale, customers migrate to Netflix-style appliance CDNs or Cloudflare for the zero-egress model.
Practice saying it out loud
- Q1Estimate the bandwidth required for YouTube at 1B users streaming 1 hour/day each at 5 Mbps.
- Q2Estimate the AWS egress cost for a system serving 100 GB/sec sustained.
- Q3Your bandwidth estimate is 200 Gbps. Can a single AWS region handle it? What architecture do you propose?
- Q4Why does Netflix operate its own CDN? Why not just use AWS CloudFront?
- Q5Your system serves 1 GB/sec egress. What is the monthly cost, and at what scale does the CDN become mandatory?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
QPS Estimation