Capacity Planning for Engineers: Back-of-the-Envelope Estimation

"Will this design hold up?" Before load tests and dashboards exist, the answer comes from estimation: turning business assumptions (users, actions, data sizes) into technical numbers (requests per second, storage, bandwidth, servers). Back-of-the-envelope math is a core system design skill. It tells you which problems are real and which are imaginary.

#Key takeaways

• Start from business drivers: daily active users, actions per user, data per action.
• Convert to average and peak QPS. Peaks are commonly 2–10× the average, depending on traffic patterns.
• Estimate storage (with replication and growth), bandwidth and compute.
• Little's Law links throughput, latency and concurrency, which is useful for sizing pools and workers.
• Keep headroom (commonly 30–50%) and revisit estimates with real data.

#Handy numbers

text1 day ≈ 86,400 s ≈ 10^5 s (round for quick math)
1 month ≈ 2.6 million s;  1 year ≈ 31.5 million s
1 KB = 10^3 bytes, 1 MB = 10^6, 1 GB = 10^9, 1 TB = 10^12 (decimal, fine for estimates)
1 million requests/day ≈ 12 requests/s average

Also keep rough latency figures in mind (latency numbers every engineer should know).

#Step 1: Traffic (QPS)

Example: a photo-sharing app

• 5 million daily active users (DAU).
• Each user views 30 feed pages and uploads 0.2 photos per day.

textFeed reads:  5M × 30 = 150M/day → 150M / 86,400 ≈ 1,740 QPS average
Uploads:     5M × 0.2 = 1M/day  → ≈ 12 QPS average
Peak factor: assume 4× → ~7,000 read QPS, ~50 upload QPS at peak

Read/write ratio ≈ 150:1. Caching and read scaling will dominate the design (caching strategies).

Peak factors: consumer apps have daily cycles (evening peaks); B2B tools peak during business hours; e-commerce spikes around promotions. Use real traffic curves when you have them.

#Step 2: Storage

textPhotos: 1M uploads/day × 2 MB avg = 2 TB/day
        × 365 = ~730 TB/year of originals
Thumbnails/resized variants: +20–30%   → ~900 TB/year
Replication/durability overhead: object storage handles this internally (priced in)
Metadata: 1M rows/day × 1 KB = 1 GB/day → ~365 GB/year (plus indexes, ×2–3)

Conclusions: images belong in object storage served via a CDN (what is a CDN); metadata fits comfortably in a relational database for years (SQL vs NoSQL).

Always consider retention (do you keep data forever?), backups (multiply database storage), and indexes (often a large fraction of table size).

#Step 3: Bandwidth

textFeed page views at peak: 7,000/s × (say) 10 thumbnails × 50 KB ≈ 3.5 GB/s ≈ 28 Gbps

That's why thumbnails must come from a CDN rather than your origin servers, and why image optimization (right sizes, modern formats) directly affects cost.

#Step 4: Compute

Estimate per-instance throughput from benchmarks or experience, then divide:

textIf one app instance handles ~500 feed requests/s at target latency:
Peak 7,000 QPS / 500 ≈ 14 instances → add headroom (÷ 0.6 utilization target) ≈ 24 instances
Plus redundancy across zones: at least N+1 per zone

Per-instance throughput should come from load testing, not guesses (load testing guide).

#Step 5: Concurrency with Little's Law

Little's Law: L = λ × W

• L = average number of requests in the system (concurrency).
• λ = arrival rate (requests per second).
• W = average time each request spends in the system.

textDatabase queries: 7,000 req/s × 2 queries each = 14,000 queries/s
Avg query time 2 ms → concurrency ≈ 14,000 × 0.002 = 28 concurrent queries

So the database needs capacity for roughly 28 concurrent queries on average (more at peaks and tails). This informs connection pool sizing (connection pooling explained) and replica counts.

The same law sizes worker pools for queues:

textThumbnail jobs: 50 uploads/s at peak × 3 variants = 150 jobs/s; each takes 0.4 s
Concurrency needed ≈ 150 × 0.4 = 60 concurrent workers (+ headroom)

#Step 6: Cost estimate

Translate resources into money early:

• Compute: instance count × hourly price × hours.
• Storage: TB-months × price, plus request costs for object storage.
• Bandwidth / CDN egress: often a major line item for media-heavy apps.
• Managed services: databases, queues, caches.
• AI/LLM usage: tokens × price, often the fastest-growing cost for AI features (LLM cost optimization).

Rough cost modeling frequently changes design decisions: image compression, caching and data retention policies can save more than any instance-type optimization.

#Step 7: Headroom and growth

• Plan for growth over your planning horizon (for example, 12–18 months at expected growth rates).
• Keep utilization targets below 100%. Commonly 50–70% for CPU on critical services, which leaves room for spikes and failover.
• Account for failure scenarios: if one availability zone of three fails, can the remaining two handle peak load?
• Plan for known events: launches, sales and seasonal peaks.

#Turning numbers into decisions

That last row is important. Estimation often proves you don't need complex architecture (system design fundamentals).

#Validate and iterate

Estimates are hypotheses. Once you have real traffic:

• Compare actual QPS, payload sizes and growth to your assumptions.
• Track saturation metrics and cost per unit (per user, per order, per request).
• Re-forecast quarterly, and before major launches (how to scale a web application).

#FAQ

#How accurate do back-of-the-envelope estimates need to be?

Within an order of magnitude is usually enough to make architectural decisions. The goal is to know whether you need one server or a hundred, gigabytes or petabytes, and not to predict exact figures.

#What peak-to-average ratio should I use?

Use real traffic data when available. Without it, a 2–5× factor is a common assumption for many web apps, higher for event-driven spikes like ticket sales or flash sales.

#What is Little's Law used for in engineering?

It relates arrival rate, latency and concurrency. Engineers use it to size thread pools, connection pools, worker counts and queue capacity, and to understand how latency increases affect concurrency.

#How much headroom should a system have?

Enough to absorb normal peaks, sudden spikes and the loss of a failure domain (such as an availability zone) while staying within SLOs. Many teams target 50–70% utilization for critical components.