Back to System design
Numbers Every Engineer Should Know
easyYou do not need these memorised to be a good engineer. You need them in an interview, because every estimate you make rests on them, and a candidate who reaches for real magnitudes sounds different from one who says "fast" and "a lot".
ScaleN/A — reference table
Key Concepts
1
Use orders of magnitude, not precision. Nobody is checking whether a disk seek is 8 ms or 10 ms. What
matters is knowing it is roughly ten thousand times slower than a memory read, because that ratio is what
decides whether your design touches disk on the request path.
Use orders of magnitude, not precision.
2
Three ratios carry most of the weight. Memory is about 100x faster than SSD, SSD is about 100x faster
than a disk seek, and a cross-continent round trip is about 100x a same-region one. Chain them and you can
justify caching, local replicas and precomputation without memorising a table.
Three ratios carry most of the weight.
3
Calibrate on the second, not the millisecond. A year is about 31.5 million seconds — close enough to
π x 10^7 to be a party trick, and useful because "per year" figures turn into "per second" figures by
dividing by 30 million. A day is 86,400 seconds; most capacity arithmetic in interviews starts by dividing
a daily figure by that.
Calibrate on the second, not the millisecond.
4
Know the sizes of the things you store. A UUID is 16 bytes raw and 36 as a string. A timestamp is 8. An
IPv4 address is 4. A short text field is tens of bytes; a typical HTML page is tens of kilobytes; a
photograph is a few megabytes. Getting a row size roughly right is what turns "a lot of data" into "1.2 TB
a year, so one machine".
Know the sizes of the things you store.
5
The number people get wrong most often is network bandwidth inside a datacentre. 10 Gbps is 1.25 GB per
second. Copying a terabyte between nodes therefore takes about 13 minutes at line rate, and much longer in
practice. That single figure decides whether a rebalance is an afternoon or a week.
The number people get wrong most often is network bandwidth inside a datacentre.
6
What the interviewer is probing.
What the interviewer is probing.
7
1. "Roughly how long does a disk seek take versus a memory read?" Probing: whether you hold
magnitudes, not exact figures. Stalls: "I would have to look it up." Moves up: a memory read is
around 100 nanoseconds and a disk seek a few milliseconds — roughly ten thousand times slower, which
is the ratio that matters.
1. "Roughly how long does a disk seek take versus a memory read?"
8
2. "How much does a round trip within a datacentre cost?" Probing: the number that drives
chattiness. Stalls: "It is fast." Moves up: about half a millisecond, versus roughly 150
milliseconds across continents — which is why a design with fifty sequential calls is already too
slow.
2. "How much does a round trip within a datacentre cost?"
9
3. "Why do interviewers ask for these at all?" Probing: whether you see the point. Stalls:
"To test memory." Moves up: they want to see you reach for real magnitudes when estimating,
because every capacity answer rests on them.
3. "Why do interviewers ask for these at all?"
10
4. "How precise do your numbers need to be?" Probing: the calibration. Stalls: "Very
precise." Moves up: within an order of magnitude — nobody checks whether a seek is 8 or 10
milliseconds, but confusing microseconds with milliseconds breaks the design.
4. "How precise do your numbers need to be?"
Latency numbers
L1 cache reference ~1 ns Branch mispredict ~3 ns L2 cache reference ~4 ns Mutex lock/unlock ~17 ns Main memory reference ~100 ns Compress 1 KB (snappy) ~2,000 ns (2 us) Read 1 MB sequentially from memory ~3,000 ns (3 us) SSD random read ~16,000 ns (16 us) Read 1 MB sequentially from SSD ~49,000 ns (49 us) Round trip within the same datacentre ~500,000 ns (500 us) Read 1 MB sequentially from disk ~5,000,000 ns (5 ms) Disk seek ~10,000,000 ns (10 ms) Round trip Mumbai -> Singapore ~60 ms Round trip Mumbai -> Virginia ~200 ms
The three ratios worth remembering instead of the table:
memory : SSD ~ 1 : 100
SSD : disk seek ~ 1 : 100
same-region : global ~ 1 : 100 What each one buys you in an argument
- Memory vs SSD justifies an in-process or Redis cache.
- SSD vs seek justifies sequential access patterns and LSM trees.
- Regional vs global justifies read replicas near users, and
explains why a synchronous global quorum is expensive.Throughput and size
Time
Seconds in a day 86,400
Seconds in a year ~31,500,000 (pi x 10^7)
-> divide a yearly figure by 30 million for per-second Bandwidth
1 Gbps 125 MB/s
10 Gbps 1.25 GB/s
Copy 1 TB at 10 Gbps (line rate) ~13 min
Copy 1 TB at 1 Gbps ~2.2 hours Single-node capability (rough, modern hardware)
Redis GET/SET 100k+ ops/s
PostgreSQL simple indexed reads 10k-50k/s
PostgreSQL write transactions 2k-20k/s
Kafka broker, sequential writes 100s MB/s
Nginx static responses 50k+ req/s Sizes to estimate rows with
Boolean / small int 1-4 B
Timestamp 8 B
UUID (binary / string) 16 / 36 B
IPv4 / IPv6 4 / 16 B
Short text field (name, title) 20-100 B
URL ~70 B
Typical DB row 100-500 B
HTML page (compressed) 20-50 KB
Photo (phone, JPEG) 2-5 MB
Minute of 1080p video ~40 MBUsing them in an estimate
The pattern: daily volume -> per second -> per row -> per year.
Worked example, an activity log:
Daily events 500,000,000
Per second 500M / 86,400 = ~5,800
At 3x peak = 17,400 Row: user id 8 B + event type 4 B + target id 8 B
+ timestamp 8 B + metadata ~50 B = ~78 B
Daily bytes 500M x 78 B = 39 GB
Yearly 39 GB x 365 = 14.2 TB
With 3x replication = 42.6 TB Now the design questions answer themselves:
- 17,400 writes/s at peak is beyond one PostgreSQL node for
this shape, so either batch the writes or use a store built
for sequential appends.
- 14 TB/year means retention policy is a product decision, not
an afterthought.
- 39 GB/day of new data at 10 Gbps takes ~30 seconds to move,
so a daily export is trivially affordable. The habit to build
State the assumption, do the division out loud, then say what
the number rules out. The arithmetic is not the point; the
conclusion you draw from it is.