Lesson 03:Stop Guessing System Capacity! Master Back-of-the-Envelope Estimation

System Design Interview Preparation Using Varastra: Calculate Orders per Second, Storage Requirements, Peak Traffic, Bandwidth, and Infrastructure Capacity with Simple Math.

Tagline: Don't Memorize Numbers. Learn to Estimate Like an Architect.

You do not need exact data in a system design interview. You need a rough number, built in clear steps. A rough number with a clear chain beats a wild guess every time.

The problem at Varastra

Varastra is an online store for Indian ethnic wear. It sells sarees, kurtas and lehengas. Maya is practicing with Joel.

Joel asks:

How big is the order tracking page?

Maya answers:

Big. Maybe a million requests a second?

Joel asks where the number came from. She cannot say. She guessed.

A guess like that is dangerous. If it is too high, she designs a huge system for a small problem. If it is too low, the site falls over on a busy night. So they start again, one step at a time.

The diagram at a glance

The diagram has three parts.

• A chain of steps. From orders per day to seconds, to peak, to storage.
• Numbers to remember. 1 day = 86,400 seconds. 30 days = 2,592,000 seconds. 365 days = 31,536,000 seconds. 1 byte = 8 bits.
• The "nines" table. How much downtime each level of availability allows.

Step 1: Start from one number

Assume Varastra has 20,000 orders on a normal day. This is made up.

Orders per second, on average: 20,000 ÷ 86,400 = about 0.23.

Step 2: Add a peak

Traffic is not flat. Evenings and sale days are busier. Take the average and multiply by a peak factor. Assume 10 times. This is also made up.

Peak orders per second: about 2.3. You build for the peak, not the average.

Step 3: Size the tracking page

More assumptions, all made up:

• Orders in transit at any time: 3 days of orders = 60,000.
• Each open order is viewed 4 times a day.
• Each order gets 6 status updates in its life.
• Each history row takes 200 bytes.

Pause and predict. If orders double to 40,000 a day, what happens to the peak page views a second? Write your guess, then run the script.

Here is the whole chain as a short script.

SECONDS_PER_DAY = 86_400
orders_per_day = 20_000          # made up
peak_factor = 10                 # made up
days_in_transit = 3              # made up
views_per_open_order_per_day = 4 # made up
updates_per_order = 6            # made up
bytes_per_row = 200              # made up

avg_orders = orders_per_day / SECONDS_PER_DAY
open_orders = orders_per_day * days_in_transit
views_per_day = open_orders * views_per_open_order_per_day
updates_per_day = orders_per_day * updates_per_order
rows_per_year = updates_per_day * 365

print(f"orders per second: avg {avg_orders:.2f}, peak {avg_orders*peak_factor:.1f}")
print(f"open orders: {open_orders:,}")
print(f"page views per day: {views_per_day:,}")
print(f"page views per second: avg {views_per_day/SECONDS_PER_DAY:.1f}, peak {views_per_day/SECONDS_PER_DAY*peak_factor:.0f}")
print(f"updates per day: {updates_per_day:,}")
print(f"updates per second: avg {updates_per_day/SECONDS_PER_DAY:.1f}, peak {updates_per_day/SECONDS_PER_DAY*peak_factor:.0f}")
print(f"history rows per year: {rows_per_year:,}")
print(f"storage per year: {rows_per_year*bytes_per_row/1e9:.1f} GB")

Output:

orders per second: avg 0.23, peak 2.3
open orders: 60,000
page views per day: 240,000
page views per second: avg 2.8, peak 28
updates per day: 120,000
updates per second: avg 1.4, peak 14
history rows per year: 43,800,000
storage per year: 8.8 GB

Try it. Change orders_per_day to 40_000 and run the script again. Page views a second at peak go from 28 to 56. Updates at peak go from 14 to 28. Storage goes from 8.8 GB to 17.5 GB a year. Every result in the chain grows in step with orders, so double the orders gives double each result.

Step 4: Say what the numbers mean

About 28 reads and 14 writes a second at peak is a small load. 8.8 GB a year is small data. One well-run database may handle this. That is reasoning. It was not tested, and a real team would measure.

This is the reason for the estimate. It tells you not to add extras. No cache, no queue, no huge cluster. Maya can now say: "The numbers do not ask for them." Her first guess of a million requests a second was about 36,000 times too high (1,000,000 ÷ 28).

Two rounding traps

• Rounding a day to 100,000 seconds is 15.7% too high.
• Treating 1,024 as 1,000 is a 2.4% gap. This is fine for a rough estimate, but write the units.

Also keep bits and bytes apart. Network speed is often quoted in bits, and storage in bytes. 8 bits make 1 byte, so mixing them gives an 8 times error.

What the "nines" mean

"Five nines" means the system is up 99.999% of the time. The downtime allowed is easy to calculate. Here is the table for a 30-day month (2,592,000 seconds).

Google's SRE book says:

Each additional nine corresponds to an order of magnitude improvement toward 100% availability.

It also says:

An incremental improvement in reliability may cost 100x more than the previous increment.

And:

100% is probably never the right reliability target.

Google defines availability by the request success rate, not by uptime.

Takeaways

1. A rough number built in clear steps beats a wild guess.
2. Design for the peak, not the average.
3. Say what the numbers mean. Small numbers tell you not to add extra boxes.
4. Write units, and keep bits and bytes apart.