Core concepts · Back-of-the-envelope estimation

Core concepts

Back-of-the-envelope estimation

The few numbers worth memorizing, and how to use them only when they change the design.

2 min read system-design

Estimation is a design tool with one job: choose between architectures. If the number will not change a box, do not spend the opening on it. Tell the interviewer you will do the math at the point of the decision, then do it there, out loud, with round numbers.

Magnitudes worth having in your head

ThingOrder of magnitude
L1 / memory / SSD random / cross-AZ / cross-USns / 100 ns / 100 µs / under 1–2 ms / ~70 ms
In-region Redis or DB point readabout 1 ms, plus your query
A modern servertens of cores, 64–256 GB RAM, on the order of 1–10 Gbps
Seconds in a dayabout 1e5 (86,400)
Comfortable single-node Postgreslow thousands of simple writes/s, much more for reads, until you measure

These are interview numbers, not a benchmark. Say “on the order of” and move.

A pattern that does not waste time

  1. Write the daily volume from the requirement you were given, or from an assumption you state.
  2. Divide by 1e5 to get average per second. Multiply by something like 10 for a consumer peak, unless the product is a ticket drop or a flash sale, in which case the peak is the design.
  3. Multiply by the bytes you actually store, then by 2 or 3 for replicas and indexes.
  4. Ask one question: does the hot set fit in memory? Does the write rate fit one primary? Does the token bill fit the budget?

Example. 500 million short links created per year is about 16 per second average. That is one database. The redirect path at 100× that rate is a cache problem, not a shard problem. The math just told you where to spend the deep dive.

Cost-shaped math

When the scarce resource is money, estimate units times price. Two million grading calls times 1.5 thousand tokens is 3 billion tokens. If the provider allows 2 million tokens a minute, the batch takes on the order of a day of continuous sending, before retries. That single division tells you whether you need a second provider, a batch API, or a smaller prompt. It is more useful than a QPS slogan.

Latency budgets

Start from the user promise (say 300 ms). Subtract the round trips you cannot avoid. What is left is the budget for the queue, the model, or the fan-out. If the remainder is negative, the design is already wrong and you should change it before you tune anything.

Further reading

Check yourself

Answer the questions. Multiple choice is scored on this device only.

1. About how long is a round trip across the US?

2. 100 million DAU, 20 requests each per day. Rough average QPS?

3. When do you actually do the math?