How do you estimate scale and do capacity planning?

Question

Accepted Answer

**Estimation and capacity planning** — calculating expected load, data volume, and resource needs — is an important part of system design. Rough "back-of-the-envelope" calculations inform design decisions (how much to scale, what resources are needed) and are common in design interviews.

## Why estimation matters

```text
Estimating scale informs DESIGN decisions:
  → how many servers? how much storage? what database? do you need sharding/caching?
  → understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
```

## What to estimate (back-of-the-envelope)

```text
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
  → peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
```

## Useful numbers and approach

```text
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
```

## Why it matters

Understanding how to estimate scale and do capacity planning is valuable senior-level knowledge because **estimation informs system design decisions** and is a common part of design work and interviews, so it's a useful, practical skill.

Estimating scale — calculating expected load, data volume, and resource needs through rough "back-of-the-envelope" calculations — is important because **understanding the scale shapes the whole design**: knowing whether a system handles thousands or billions of requests determines how much to scale, what databases to use, and whether sharding and caching are needed, helping avoid both over-engineering (unnecessary complexity for small scale) and under-engineering (a design that can't handle the real load).

Understanding **what to estimate** — **traffic** (users, requests/sec, read/write ratios, peak vs average), **storage** (data size and growth), **bandwidth**, and **memory/cache** needs — provides the framework for sizing a system.

Understanding the **approach** — knowing rough latency numbers (memory vs SSD vs network vs cross-region), using round numbers and powers of 10, estimating order-of-magnitude rather than seeking precision, deriving resource needs from estimates to justify the architecture, and **capacity planning** (provisioning for expected load plus growth and headroom) — reflects the practical skill of making useful estimates quickly.

This is a common, expected skill in system design interviews (where back-of-the-envelope estimation demonstrates you can reason about scale) and in real capacity planning.

Since estimating scale informs key design decisions (how to scale, what resources are needed, avoiding over/under-engineering) and is a common part of system design work and interviews, and since understanding what to estimate and how (back-of-the-envelope calculations, latency numbers, capacity planning) is a practical skill, understanding how to estimate scale and do capacity planning is valuable senior-level knowledge — a useful, expected skill for system design that informs architectural decisions through rough quantitative reasoning, common in both real capacity planning and design interviews, and reflecting the ability to ground designs in realistic estimates of scale and resource needs.