Art of Codeartofcode
Lesson 10 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

2.9 How do you estimate bandwidth?

3 min read+10 XP

At the wedding: Vans bring raw food in and take cooked food out to a second venue. You count van-loads per hour in each direction.

In the system: Bandwidth is data per second over the network, in each direction:

  • Ingress = data coming in (uploads).
  • Egress = data going out (downloads). Usually much bigger for read-heavy apps.

The trap: bits vs bytes. Storage is measured in bytes (B). Network speed is measured in bits per second (bps). 1 byte = 8 bits. Forget the 8 and your answer is 8 times too small.

PicShare (assumed): each photo shown in the feed is a compressed version of about 200 KB.

  • Egress per day = 500 million views × 200 KB = 100 TB a day.
  • Per second = 100 TB ÷ 86,400 ≈ 1.16 GB a second (bytes).
  • In bits = 1.16 × 8 ≈ 9.3 Gbps on average, and about 3 times that at peak.

Ingress: 4 TB of uploads a day ÷ 86,400 ≈ 46 MB a second ≈ 370 Mbps.

That egress number is why photo and video apps serve media through a CDN (Chapter 26) instead of from their own servers.

Memory code: "Network speaks bits, storage speaks bytes. Times eight."