Back-of-the-Envelope Estimation

Back-of-the-envelope math exists to catch a design that's wrong by 1000x before you build it. It doesn't need to be precise — it needs to be roughly right and fast.

The estimation toolkit is small. Memorize these, not the formulas:

1 million   ≈ 10^6
1 billion   ≈ 10^9
1 day       ≈ 86,400 seconds  (round to 100,000 for quick math)
1 KB        = 10^3 bytes        1 MB = 10^6 bytes        1 GB = 10^9 bytes

Worked example: the URL shortener again

Assume 100 million new short links created per day, and a 100:1 read:write ratio.

Writes/sec  = 100,000,000 / 100,000 s/day ≈ 1,000 writes/sec
Reads/sec   = 1,000 × 100                 ≈ 100,000 reads/sec

Storage per link ≈ 500 bytes (URL + metadata + short code)
Storage/day       = 100,000,000 × 500 bytes ≈ 50 GB/day
Storage/year      = 50 GB × 365            ≈ 18 TB/year

Three numbers just told you a lot:

• 100K reads/sec cannot hit a single relational database directly — this design needs a cache in front of the DB (Chapter 2), full stop, before you've discussed anything else.
• 18 TB/year is not "big data" — it comfortably fits on a handful of modern disks. Sharding the database on day one, purely for storage size, would be premature.
• 1,000 writes/sec is modest — a single well-indexed database can typically handle this, so the write path doesn't need to be over-engineered.

The estimate doesn't tell you the final architecture — it tells you which parts of the design space you can immediately rule out. That's the entire point: cheap math prevents expensive mistakes.