Estimating Before Designing

Why estimate at all

The purpose of a back-of-the-envelope estimate is not accuracy. It is elimination. If the answer is forty requests per second, a single machine with a single database is correct and everything else is overengineering. If it is four hundred thousand, sharding is not optional. The estimate decides which conversation you are having.

The numbers worth memorising

A handful of reference points make arithmetic possible without a calculator. These are deliberately round.

A worked estimate

Take a link-shortening service. Ten million people use it, and each creates one link a day and follows twenty.

• Writes: 10 million/day ÷ 100,000 seconds ≈ 100 writes per second.
• Reads: 200 million/day ÷ 100,000 ≈ 2,000 reads per second.
• Read:write ratio ≈ 20:1 — this is a read-heavy system, which is the single most important thing the estimate told us.
• Storage: 10 million links/day × 500 bytes ≈ 5 GB/day, ≈ 1.8 TB/year.
• Peak: assume 3× average, so ~6,000 reads per second at the busy hour.

Now read what that implies. Two thousand reads per second is comfortably within one well-indexed database with a cache in front. One hundred writes per second is nothing at all. Under two terabytes a year fits on one machine for several years. So the correct first architecture is unglamorous: one database, one cache, several stateless API servers — and the estimate is what justifies refusing to shard.

Peak, not average

Traffic is never flat. A consumer product might see three to five times its daily average in the evening peak, and a product tied to an event can see far more than that for a short window.

You provision for peak and you pay for average, which is the entire commercial argument for elastic infrastructure. When you cannot scale elastically, the peak multiple is what sizes the fleet — and it is worth asking whether the peak can be flattened instead, by moving work off the request path and into a queue.