Bandwidth Estimation Playbook

The formula

Bandwidth = QPS × bytes per payload (then mind bits vs bytes)

⚠️ The bits-vs-bytes trap

Network capacity is quoted in bits (Gbps); your payloads are in bytes. Always convert: 1 Gbps = 125 MB/s (÷8). A NIC’s speed is the hard ceiling on a single box.

Worked example — video streaming

100K concurrent HD streams at ~5 Mbps each:

• Total = 100,000 × 5 Mbps = 500 Gbps = ~62.5 GB/s egress.
• Gate: no single server does that ⇒ this is a CDN problem; serve from edge, not origin.

Make the gate arithmetic, not intuition: one origin box’s usable egress ≈ 25 GbE × 0.7 ≈ 17.5 Gbps (protocol framing ~3–6%, retransmits, and the queueing knee eat the rest — the same 70% knee as CPU). 500 Gbps ÷ 17.5 ≈ 29 servers doing nothing but shoveling the same bytes, every one a copy of the same hot content pulling from shared storage — versus a CDN that serves those bytes from RAM at 200+ PoPs and charges less than the egress you’d pay anyway (edge egress ~$0.02–0.05/GB vs cloud origin ~$0.09/GB). The gate is not “no single server” — it is “29 servers of pure byte-pushing is strictly worse than edge on every axis: cost, latency, blast radius.”

Don’t forget egress cost

Cloud egress (data leaving the provider) is the sneaky bill — often ~$0.09/GB. High-bandwidth designs are often cost problems before they’re capacity problems (see the Cost playbook).

When bandwidth math misleads

Trap	Wrong conclusion	Fix
Confusing MB/s and Mbps	Off by 8×	Always convert: MB/s × 8 = Mbps
Only ingress or only egress	Misses video egress or backup ingress	Estimate both; CDN may dominate egress cost
Average over day	Link saturated at peak	Peak concurrent viewers × bitrate

Boundary A (edge vs origin): 100k concurrent 3 Mbps streams → 300 Gbps egress raw. With CDN edge hit ratio 90%, origin egress ≈ 30 Gbps — still plan CDN + origin separately. At 95% hit on 500 Gbps edge (HD), origin is only 25 Gbps (~3.1 GB/s) but that miss path dominates p99.

Boundary B (bits/bytes + NIC ceiling): 1 Gbps = 125 MB/s, not 1 GB/s. A 10 Gbps NIC is ~1.25 GB/s theoretical; TCP+TLS often yields ~70–80% → ~0.9–1.0 GB/s usable. Live final: 500k × 3 Mbps = 1.5 Tbps for two hours — size peak concurrent, not daily-mean Mbps.

Boundary C (east-west): client egress is not the only pipe. RF=3 replication and cross-AZ backups can move as many bytes internally as users download.

See also: Senior corrections.

---

Formulas are standard/public-domain engineering math. Approach and reference-table format adapted from the System Design Primer (CC BY 4.0), Jeff Dean’s latency numbers, the DesignGurus capacity-estimation guide, and Little’s Law.

I just read a lesson on **Bandwidth Estimation Playbook** (System Design) and want to truly understand it. Explain Bandwidth Estimation Playbook from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Bandwidth Estimation Playbook** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Bandwidth Estimation Playbook** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Bandwidth Estimation Playbook** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.