Back-of-Envelope Estimation for Architects

Many design debates dissolve once someone does the arithmetic. Should we shard? Do we need a cache? Will this fit on one machine? A five-minute estimate, accurate to within a factor of two or three, is usually enough to answer. The point is not precision; it is to find which orders of magnitude matter.

A repeatable method

1. State the question and the decision it informs.
2. List the inputs and mark each as known, estimated or guessed.
3. Use round numbers. 86,400 seconds in a day is about 100,000. A month is about 2.5 million seconds.
4. Calculate, keeping units so mistakes show up.
5. Sanity check against a known reference system.
6. Test sensitivity. Double the key input and see whether the conclusion changes.

Handy numbers to memorise

| Quantity | Approximate value | |---|---| | Seconds per day | 86,400 (about 10 to the 5th) | | Memory read | 100 nanoseconds | | SSD random read | 100 microseconds | | Same-datacenter round trip | 0.5 milliseconds | | Cross-continent round trip | 100 to 150 milliseconds | | Single database node, simple queries | thousands to tens of thousands per second | | One kilobyte times one million | one gigabyte |

Latency numbers are especially useful: they explain why ten sequential calls across regions cannot meet a 200 ms target, no matter how fast the code is.

Worked example: storage

A photo-sharing feature expects 200,000 daily active users. Assume 10 percent upload one photo a day, with an average size of 3 MB, kept for three years.

uploads per day = 200,000 x 0.10          = 20,000
storage per day = 20,000 x 3 MB           = 60 GB
per year        = 60 GB x 365             = about 22 TB
three years     = about 66 TB

Add replication or backups at 3x and you reach roughly 200 TB. Object storage handles this easily; a relational database would not be sensible. The estimate made the technology choice obvious in under a minute.

Worked example: throughput and bandwidth

Take the same uploads. 20,000 per day is about 0.23 uploads per second on average. Even with a 10x peak factor that is roughly 2 per second, or 6 MB per second inbound. A single modest server handles that. Reads are the real driver: if each user views 50 photos a day at 300 KB thumbnails, that is 200,000 x 50 x 300 KB, or 3 TB per day, about 35 MB per second sustained. This points toward a CDN, not more application servers.

Estimating cost

Convert capacity into money, since cost is a constraint like any other. If 3 TB per day leaves your network at 0.08 dollars per GB, that is about 240 dollars a day, 7,200 a month. A CDN may cut it substantially, and now you can compare options on real figures instead of intuition.

Common mistakes

• Averaging when peaks matter. Capacity is sized for peak, not mean. Use a factor of 3 to 10 depending on how bursty the traffic is.
• Forgetting overhead. Indexes, replication, metadata and backups multiply raw data size.
• Unit slips. Bits versus bytes, MB versus MiB, per second versus per day. Write units on every line.
• False precision. Reporting 22.3 TB implies accuracy you lack. Say "about 20 TB".
• Ignoring the long tail. Heavy users and large tenants often dominate load.

Close the loop

An estimate is a hypothesis. When the system runs, compare actual numbers with your prediction. If you were off by 10x, find out which assumption was wrong. Over time this calibrates your instincts, and you will learn which inputs you habitually underestimate. Keep the estimate in the design document so reviewers can challenge the inputs, which is more productive than arguing conclusions.

Key takeaways

• Estimates within a factor of two or three are enough to decide most architecture questions.
• Use round numbers, track units, and distinguish known inputs from guesses.
• Memorise a few latency and capacity reference points.
• Size for peak load and include replication and overhead.
• Compare predictions with reality afterwards to improve your judgment.