Estimating with round numbers

Part of the free System Design course on LogicWiz, in the chapter: Back-of-the-envelope estimation. The interactive whiteboard exercises and simulations run in the app.

Week 2: The number Meera could not say

"Kabir asked how many requests per second. I said 'a lot'. He said 'a lot' is not a unit."

From Meera's notebook

An estimate is a sentence with a number in it

Last week Meera could not answer "how many people open the tracking page during the IPL final?" This week she fixes that. Back-of-the-envelope estimation means getting a rough answer in a minute or two, with arithmetic you can do in your head. It tells you what size of problem you have.

You are not predicting the future. You are deciding between "one small server is fine" and "we need a fleet". Those two answers differ by a factor of a hundred. An estimate that is off by 30 percent still lands on the right side of that line.

The one conversion to memorise

A day has 86,400 seconds. Round it to 100,000 (about 10^5). You will be off by roughly 15 percent, which does not matter, and the division becomes easy.

requests per second ≈ requests per day ÷ 100,000

So 1 million requests a day is about 10 per second. 100 million a day is about 1,000 per second. Keep that pair in your head and most estimates take ten seconds.

Two more habits help. Work in powers of ten (thousand, million, billion). And write units on every line, because half of all estimation mistakes are a missing "per day" or "per user".

The same habit works for time: know your orders of magnitude, not exact figures. Rough times to remember:

  • Reading memory: well under a microsecond.
  • Reading an SSD: roughly a tenth of a millisecond.
  • A round trip inside one data centre: about half a millisecond.
  • Mumbai to Delhi and back: roughly 30 ms.
  • India to the US and back: roughly 200 ms.

The gaps are huge. One trip to the US costs as much time as about 400 round trips inside a data centre. So a page that makes five calls to another continent feels slow, however fast your servers are.

Find each of those rungs on the ladder below. Then flip the "human scale" toggle, which stretches these times to everyday durations. Compare a memory read with a trip to the US.

SwiftKart, step by step

Kabir gives Meera the facts: SwiftKart has about 2 million daily active users. A user opens the app roughly 10 times a day, and each open fetches order or tracking data once. Orders: about 500,000 a day, and each order passes through about 8 status changes (placed, packed, picked up, and so on).

Step 1, reads. 2,000,000 users × 10 opens = 20,000,000 reads a day. Divide by 100,000: about 200 reads per second on average.

Step 2, writes. 500,000 orders × 8 status changes = 4,000,000 writes a day. Divide by 100,000: about 40 writes per second.

Step 3, peak. Averages hide the evening. Dinner time, a rainy day or a match makes traffic bunch up. Pick a peak factor, the ratio of peak rate to average rate. For an app like this, 5 is a fair starting guess. Reads peak at 200 × 5 = 1,000 per second; writes at 40 × 5 = 200 per second. For the IPL final, Kabir suggests a factor of 10: reads reach roughly 2,000 per second.

Step 4, storage. One order record, with its items and status history, is about 2 KB. 500,000 orders × 2 KB = 1,000,000 KB = 1 GB a day. Over a year, 365 GB, call it roughly 0.4 TB. Keep three copies for safety and it is about 1.1 TB a year. That is small. One ordinary database server holds it with room to spare.

Step 5, bandwidth. A tracking response is about 5 KB. At the peak of 1,000 reads per second, that is 1,000 × 5 KB = 5 MB per second, about 40 megabits per second (multiply bytes by 8). A single ordinary network link is fine.

Read the result back as one sentence. "At peak, about a thousand reads and two hundred writes a second, a terabyte a year, and 40 Mbps out." That sentence is the estimate. It also tells Meera something real: this system is not huge. She does not need a fleet. She needs a sensible database and some headroom (spare capacity above the expected peak).

flowchart LR
  A["2M users x 10 opens"] --> B["20M reads/day"]
  B --> C["divide by 100K"]
  C --> D["200 reads/s avg"]
  D --> E["x5 peak"]
  E --> F["1,000 reads/s"]

Try it on a different shape

Not every system looks like SwiftKart. A URL shortener is the classic opposite: very few writes, a flood of reads. The calculator below is preloaded with one. It takes about 3.3 million new links a day and 100 reads for each. Change the numbers and watch what moves.

Notice that writes come out near 40 per second while reads are around 4,000 on average, a hundred times more. That ratio, not the user count, is what will decide the design. Storage also differs: 500-byte links add up to roughly 600 GB a year before copies.

💡 Tip: Always compute reads and writes separately. They scale differently, they cost differently, and a system that is easy to read can still be hard to write.

Roughly right beats precisely wrong

A common worry in mock interviews is, "My numbers must be exact, or I will lose marks." So candidates freeze when they cannot recall the true number of users. Or they spend two minutes on 86,400 × 365. Nobody checks your decimals. The interviewer is checking three things: that you state your assumptions, that your arithmetic is consistent, and that you use the result to make a decision.

If you assumed 10 opens a day and the real figure is 7, the design does not change. If you assumed 10 million users and the real figure is 100 million, the design does change. A stated assumption lets the interviewer correct you in five seconds. Being roughly right and transparent beats being precisely wrong and silent.

⚠️ Warning: The real errors are by factors of ten: forgetting "per user", mixing KB and MB, or mistaking a day for a second. Check your units and the number of zeroes, not the third digit.

📌 Summary: Requests per second is requests per day divided by 100,000. Multiply by a stated peak factor, and compute reads and writes separately. Aim to be roughly right, with every assumption said aloud.

What Meera learns next

Meera now has numbers: a thousand reads and two hundred writes a second at peak. Next, what those numbers say about which components she needs, and where one machine stops being enough.

Check your understanding

  1. A new SwiftKart feature will get about 50 million requests a day. Roughly how many is that per second, on average?
  2. Meera computes about 200 reads a second on average for the tracking page. Kabir asks if that is what the database must handle at dinner time. What should she do?
  3. SwiftKart stores 500,000 orders a day at about 2 KB each. Roughly how much is that in a year, before keeping copies?
  4. You assumed 10 app opens per user per day. The interviewer says the real figure is closer to 7. What now?