Art of Codeartofcode
Lesson 15 of 19

2. Back-of-Envelope Estimation

1
The picture to keep in your head
2
2.1 Why estimate at all?
3
2.2 Which units and sizes should you know?
4
2.3 What time shortcuts make the maths easy?
5
2.4 Which latency numbers should every developer know?
6
2.5 How do you turn daily users into requests per second?
7
2.6 Why does the read/write ratio matter?
8
2.7 Why size for the peak, not the average?
9
2.8 How do you estimate storage over the years?
10
2.9 How do you estimate bandwidth?
11
2.10 How much memory does the cache need?
12
2.11 How many servers do you need?
13
2.12 How do you round, and how do you know you're not way off?
14
Memory card and where the analogy breaks
15
Practice: five levels
16
Interview questions
17
Solutions
18
Sources
19
Code lab
2. Back-of-Envelope Estimation

Practice: five levels

3 min read+10 XP

Assignments

Five levels. Do them in order. Answers are in "Solutions" at the end, so try first.

Level 1: Think (no code)

A. For each system, which number is most likely to drive the design: read requests, write requests, storage, or bandwidth? Say why in one line.

  1. A URL shortener.
  2. A video streaming app.
  3. A service collecting logs from 1,000 servers, each sending 100 lines a second.
  4. An online exam that 2 lakh (200,000) students start at exactly 10:00 am.
  5. A photo backup app where people upload all their phone photos and rarely look at them again.

B. Each estimate below has a problem. Find it.

  1. "We get 1 billion requests a month. That's 1 billion ÷ 86,400 ≈ 11,600 requests a second."
  2. "Each video stream is 5 MB a second, so 1,000 viewers need a 5 Gbps link."
  3. "We get 300 requests a second on average, so 3 servers at 100 a second each is enough."

Level 2: Calculate

A video app (assumed numbers):

  • 5 million daily active users, each watching 30 minutes a day.
  • Video streams at 5 Mbps (megabits per second).
  • 50,000 new videos uploaded a day, 500 MB each.
  1. Total video data sent to viewers per day, in PB.
  2. Average egress bandwidth, in Gbps. And at a peak factor of 3?
  3. Storage for one year of uploads (one copy), in PB.
  4. Which of these three numbers would you raise first with the interviewer, and why?

Level 3: Build

Write a small Python function estimate(...) that takes:

  • daily active users, reads per user, writes per user,
  • size of each write (bytes), size of each read (bytes),
  • peak factor (default 3), years (default 1), replicas (default 1), cache fraction (default 0.2),

and returns: average read and write requests per second, peak reads per second, read/write ratio, total storage in bytes, egress in Gbps, and cache size in bytes. Add servers_needed(peak_rps, rps_per_server, target_utilisation=0.6, spare=1).

Check that for PicShare (10M users, 50 reads and 0.2 writes each, 2 MB writes, 200 KB reads) you get:

  1. About 5,787 reads and 23 writes a second, about 17,361 at peak, ratio 250.
  2. 1.46 PB a year for one copy, 4.38 PB with 3 replicas.
  3. About 9.26 Gbps egress.
  4. 30 servers at 1,000 requests a second each.

Level 4: Debug

A teammate's capacity script says PicShare needs only about 1.2 Gbps of egress. The network team orders links for that, and on launch day the photos crawl.

python
  1. Find the bug. Explain step by step why the links were too small, and by how much.
  2. Fix it.
  3. Name one more thing the script ignores that would make the links too small even after the fix.

Level 5: Design

Estimate for "Design a chat app", with these agreed assumptions:

  • 50 million daily active users, each sending 40 messages a day.
  • A text message is about 100 bytes. 5% of messages carry a photo of about 200 KB.
  • Peak factor 3. Keep messages for 1 year.
  • One chat server handles about 5,000 messages a second (assumed). Run at 60%, keep 1 spare.

Deliver:

  1. Messages per second, average and peak.
  2. Text storage for a year.
  3. Media storage for a year.
  4. Ingress bandwidth for media, in Gbps (average).
  5. Number of chat servers.
  6. Which number drives the design most, and what it points you to.