System design interviews always start with “estimate the scale.” Engineers without production experience guess numbers and move on. Engineers who’ve been paged at 3am because they guessed wrong take this seriously. Capacity planning is the discipline of estimating resource requirements before you run out of them.

The Estimation Framework#

Start with requests per second. Then translate into resource requirements: CPU, memory, network bandwidth, storage.

Example: URL shortener serving 100 million active URLs.

Reads: typical URL shorteners are heavily read-biased, maybe 100:1 read-to-write. If 1 million new URLs are created per day (11.5 writes/second), reads are ~1150 per second.

Each read response is tiny: 200 bytes. Network bandwidth: 1150 * 200 bytes = 230 KB/s. Trivial.

If 10% of URLs are “hot” and account for 90% of traffic: cache 10 million URLs in Redis. At ~100 bytes per URL (ID + redirect target), that’s 1 GB of memory. Cheap.

Storage: 100 million URLs, each 200 bytes of metadata = 20 GB. Easily fits in one MySQL database with headroom for years.

Translating QPS to Servers#

A single application server handling redirect requests (Redis cache hit, return 301) can handle 10,000 requests per second. At 1150 requests per second, you need 1 server with comfortable headroom. Add a second for redundancy.

At the peak case (a viral URL gets 100,000 requests per second): 10 servers. This is the case to plan for, not the average.

graph TD A[1 million URLs created per day] --> B[11.5 writes per second] B --> C[100:1 read-to-write: 1150 reads per second] C --> D[Each server: 10K QPS capacity] D --> E[2 servers for normal load] F[Viral spike: 100K QPS] --> G[10 servers needed at peak] G --> H[Auto-scaling handles burst] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

The Numbers You Need to Know#

Memorize these approximations:

Hard disk sequential read:  200 MB/s
SSD sequential read:        500 MB/s
Memory read:                10 GB/s
Network (1GbE):             100 MB/s
Network (10GbE):            1 GB/s
Disk seek time:             10 ms
SSD random access:          0.1 ms
Memory access:              100 ns
Redis read:                 0.1-0.5 ms
MySQL query (index hit):    1-5 ms

These numbers let you reason about bottlenecks. If you need to read 10 GB/s and your server has 1GbE, the network is the bottleneck before CPU or memory.

Where Plans Go Wrong#

Uniform load assumption: you estimate 1000 requests/second average. But traffic peaks at 5x average at lunch on weekdays. Your 1000 RPS estimate requires 5000 RPS capacity.

Ignoring secondary effects: you estimated CPU for request processing but forgot that each request writes to a log. The log write volume becomes the disk bottleneck.

Not accounting for data locality: a sharded system that needs to scatter-gather across 10 shards for a single query multiplies latency by the number of shards, not divides it.

At Oracle#

We planned capacity for a new 5G network function based on the number of concurrent connections the specification required. What we missed: each connection state change required writing to a distributed store. At peak subscriber count, the write rate to that store was 50x what we had calculated, because state changes per connection were much more frequent than the spec’s steady-state assumption. The store saturated. We had to double its capacity emergency. Peak behavior, not average behavior, is what you need to plan for.

What I’m Learning#

Capacity planning is mostly about knowing the right order-of-magnitude numbers and finding the bottleneck before it finds you. The estimation in a system design interview is a proxy for “can this engineer think through resource constraints?” The answer always starts with QPS, then traces through to the bottleneck.

What capacity planning mistakes have you made that cost you a production incident?