Turn product assumptions into rough QPS, bandwidth, and storage numbers before choosing components.
What problem are we solving?
System design starts with an order-of-magnitude estimate. The goal is not precision — it is exposing whether an architecture is even plausible.
Live simulation
updates every 1s
Avg QPS115.7
Peak QPS463
Peak bandwidth14.8 Mbps
Controls
10000000
4x
4 KB
Live metrics
Average QPS115.7
Peak QPS463
Peak bandwidth14.8 Mbps
30-day raw request volume300.0M
What just happened?
Start with volume, divide by seconds, then apply a peak multiplier. Payload size turns request rate into a rough bandwidth target. Every later architecture choice should be consistent with these numbers.
Try this
Traffic spike
Set peak traffic to 10× and payload to 16 KB. Decide whether one server, a CDN, or a load-balanced fleet makes sense.
Which estimate would you calculate next: storage, cache size, or database connections?
Key takeaway
Back-of-the-envelope math is the bridge between a product requirement and a credible architecture.