Calculators¶
Prerequisites: Requirements & Estimation, Engineering Math
Back-of-envelope math is not decoration. It is how you decide whether the first design is a laptop Postgres or a sharded cluster — before you draw Kafka.
This hub hosts the same capacity inputs used in requirements estimation (cap-dau and friends) plus Little's Law and availability budgets.
Capacity estimator¶
Fermi numbers, not a quote from procurement. Change DAU, requests/day, peak factor, payload, replication. Read the flags: they tell you which bottleneck appears first.
avg QPS = DAU × rpd / 86400 · peak QPS = avg × peak · miss QPS = peak reads × (1 − hit). Storage/day ≈ write QPS × 86400 × payload × RF. Same IDs as the requirements-estimation page so both stay wired to window._cap.
Same calculator lives on Requirements & Estimation when that page is filled in.
Little's Law & availability¶
Little's Law: (L = \lambda W)
- (L) — average number of requests in the system (in-flight)
- (\lambda) — arrival rate (req/s)
- (W) — average time in the system (seconds)
If you take 2000 QPS at 50ms, you have 100 concurrent requests. That is thread-pool size, DB connections, and "why did we melt at 2× traffic with the same p50."
Nines are a downtime budget, not a feeling:
| Availability | Downtime / month (30.44 d) |
|---|---|
| 99% (2 nines) | ~7.3 hours |
| 99.9% (3) | ≈ 43.8 min |
| 99.99% (4) | ≈ 4.38 min |
| 99.999% (5) | ≈ 26 s |
A 30-minute deploy that pages the fleet is your monthly 3-nines budget.
How to say it in an interview
"10M DAU, 20 requests, 8× peak → about 18k peak QPS. At 50ms we need ~900 in-flight. Three nines is 44 minutes a month — I will not spend that on a blocking deploy."
Quick identities¶
QPS_avg = DAU × requests_per_user / 86_400
QPS_peak = QPS_avg × peak_factor # 3–10 typical consumer; 2–3 B2B
in_flight = QPS_peak × latency_s # Little
storage_day = writes_per_s × 86_400 × bytes × RF
bandwidth = QPS_peak × bytes
Fan-out: if one user request becomes 8 RPCs, (\lambda) for the leaf is 8×. p99 of the parent is dominated by the slowest child (see tail latency).
Interview Questions¶
Q: 1M DAU, 10 requests/user/day, 5× peak. QPS?
"10M requests/day ÷ 86400 ≈ 116 average QPS. Peak ≈ 580 QPS. I would still design the DB for a few thousand — estimation is order-of-magnitude, and we will cache."
Q: We need 99.99%. Can we take a 10-minute failover?
"No. 99.99% is about 4.4 minutes a month. A 10-minute regional failover once blows the SLO. Either make failover faster (health checks, pre-warmed capacity, not DNS TTL=300) or sell 99.9% honestly."
Q: Product wants five nines on checkout. What do you actually negotiate?
"26 seconds a month is not an engineering number — it is an organizational one: dual-region active-active, no blocking deploys, dependency SLOs tighter than ours, and a cost that is usually 3–5×. I would split SLIs (place order vs generate invoice), put five nines only on authorize+capture, and keep catalog at three. Then show the $ and the page that fires if anyone adds a sync PDF render on the checkout path."
Key Takeaways¶
Remember
- Capacity math exists to find the first bottleneck, not the invoice
- (L=\lambda W) turns latency into concurrency
- 99.9% ≈ 43.8 min/mo; 99.99% ≈ 4.38 min; 99.999% ≈ 26 s
- Peak and miss QPS size the database; average QPS sizes the slide deck
- Nines are a budget you spend on deploys and incidents