The estimation chain

Almost every estimate follows one chain. You start with users and behavior, then multiply your way to infrastructure. Each arrow is one multiplication. The skill is picking sensible multipliers and saying them out loud, so a listener can challenge an assumption instead of your arithmetic.

We'll walk the chain with one example. An app has 10 million daily active users. Each user makes 20 requests a day. One request in ten is a write of 500 bytes. Each response is 1 KB.

Step 1: daily users to requests per day

Start with daily active users (DAU). If you're given monthly actives (MAU) instead, DAU is often 20 to 50% of MAU for a social product, and much lower for a utility.

10,000,000 users × 20 requests = 200,000,000 requests/day

Step 2: requests per day to QPS

Divide by 86,400, then apply a peak factor. A global product has a softer peak because time zones overlap. A product concentrated in one country has a sharper one.

200,000,000 ÷ 86,400  ≈ 2,300 requests/s average
2,300 × 3 peak factor ≈ 7,000 requests/s peak

Step 3: storage

storage per year = bytes per record × records per day × 365 × replication × overhead

Writes are 1 in 10 requests, so 20 million writes a day. At 500 bytes each, that is 10 GB a day, or about 3.65 TB a year before copies. Multiply by 3 for replication, then by 2 for overhead: about 22 TB provisioned.

People forget the last two terms. Replication is typically 3 times for a database or replicated log. Object storage that uses erasure coding internally needs about 1.3 to 1.5 times, which is why it is cheap. Overhead covers indexes, row headers, free space in pages, write-ahead logs and backups. For a table with a couple of secondary indexes, doubling the raw size is a fair first guess.

Step 4: bandwidth

bandwidth = peak QPS × bytes per response
7,000 × 1 KB = 7 MB/s ≈ 56 Mbps

Do ingress (uploads) and egress (downloads) separately, because egress is where the money goes. As of when this was written, list prices for internet egress from a major cloud started near $0.09 per GB and fell toward $0.05 per GB at high volume. CDNs and committed contracts are cheaper, and some object stores charge no egress at all. Network links are quoted in bits, so 1 GB/s ≈ 8 Gbps.

Step 5: servers

servers = peak QPS ÷ QPS per server ÷ target utilization, then add redundancy
7,000 ÷ 1,000 ÷ 0.6 ≈ 12 servers

Target 50 to 70% utilization at peak, not 100%. Queueing delay grows fast as a server nears saturation. Then add redundancy. At least N+1 is the floor. Spreading across three availability zones is better, so losing one zone doesn't overload the rest. Here that means about 15 servers across three zones.

Common mistakes

• Sizing servers from average QPS. Average QPS sets cost. Peak QPS sets capacity.
• Forgetting replication and overhead. Raw storage times six is a common result, and it is the number you will pay for.
• Planning for 100% utilization. A server at its limit has no room for a spike.

Check yourself

1. Why size servers on peak QPS instead of the daily average? The system has to survive its busiest minute. The average is the right number for cost, not for capacity.

2. A table holds 500 GB of raw data per year, with 3 replicas and an overhead factor of 2. How much should you provision? About 3 TB (500 × 3 × 2 = 3,000 GB).

Key takeaways

• The chain is users, requests per day, average QPS, peak QPS, then storage, bandwidth and servers.
• Storage is record size × records × 365 × replication × overhead. Don't skip the last two terms.
• Egress is often the largest line on the bill. At list prices, CDN and pricing decisions matter.
• Target 50 to 70% utilization at peak, and spread servers across zones.

Further learning

Next, run the whole chain on a realistic app in a worked example for a Twitter-like app.