Back-of-the-envelope estimates

System design Junior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Predict the output

What does the estimate print?

Python 3.13
new_urls_per_month = 100_000_000
seconds_per_month = 30 * 24 * 3600
writes_per_s = new_urls_per_month / seconds_per_month
reads_per_s = writes_per_s * 100  # 100:1 read/write ratio
bytes_per_row = 500
five_year_tb = new_urls_per_month * 60 * bytes_per_row / 1e12
print(round(writes_per_s), round(reads_per_s), five_year_tb)

Options
Hint 1 of 1

100,000,000 / 2,592,000 ≈ ?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A 39 3858 3.0

Correct. About 39 writes/s, 3,858 reads/s, 3 TB over five years.

A 30-day month has 2,592,000 seconds, so 100 M writes is about 39 a second and 100× that is about 3,858 reads. Five years is 60 months × 100 M rows × 500 B, which is 3 × 10¹² B or 3 TB.

Why not the others?
  • B 39 39 3.0. Reads are 100× writes.
  • C 3858 39 3.0. Writes and reads are swapped.
  • D 39 3858 0.25. 100M × 60 months × 500 B is 3 × 10¹² bytes.

30-second answer

Turn the product numbers into requests per second, storage and bandwidth with round figures, saying assumptions out loud. A month is about 2.6 million seconds, so 100 million new items a month is roughly 40 writes per second; multiply by the read/write ratio for reads, and by row size and retention for storage. The point is the order of magnitude, which decides whether one database is enough, whether you need caching, and where the bottleneck sits.

Practise saying it · 30 s. No recording, just a timer

Estimate a system.

Say your answer out loud, then check which of these points you covered:

  • Assumptions aloud
  • Per-second rates
  • Storage with retention
  • Peak vs average
  • What it implies

Deep dive

Peak traffic is often 2–3× the average; design for peak.

Know rough latencies: memory reference in nanoseconds, same-datacentre round trip about half a millisecond, cross-continent about 100 ms or more.

One Postgres instance handles thousands of simple queries per second on good hardware; measure your own.

State assumptions so the interviewer can correct them.

A URL shortener in four lines of arithmetic Ran on Python 3.13.5 · mypy --strict
Python 3.13
new_urls_per_month = 100_000_000
seconds_per_month = 30 * 24 * 3600
writes_per_s = new_urls_per_month / seconds_per_month
reads_per_s = writes_per_s * 100  # 100:1 read/write ratio
bytes_per_row = 500
five_year_tb = new_urls_per_month * 60 * bytes_per_row / 1e12
print(round(writes_per_s), round(reads_per_s), five_year_tb)

Common mistakes

  • Precise arithmetic that wastes time.
  • Ignoring peak versus average.
  • Forgetting replication when estimating storage.

Senior take & follow-ups

State assumptions, convert to rps, storage and bandwidth, then say what the numbers imply.

Follow-up questions

Think of your answer first, then open the hint.

  1. How many seconds in a month?

    Show hint

    About 2.6 million.

  2. Why estimate at all?

    Show hint

    It tells you which components you actually need.

Suggest a fix if something here is wrong or out of date.