Part 8 · Lesson 8.2
Ninety Seconds of Arithmetic
Where we are: lesson 1.3 taught napkin math with time to think. Lesson 8.1 gave estimation about four minutes of a 45-minute interview. This lesson is about doing it quickly and accurately while someone watches.
What you’ll learn
- A one-page sheet of numbers worth knowing by heart
- Templates that turn users into requests, storage and bandwidth in seconds
- Rounding tricks that keep mental arithmetic fast and safe
- Practice drills, with worked answers
Lesson 8.2 Ninety Seconds of Arithmetic
Step 1 of 8 · 1 min · The story
In one of her practice runs, Sana was asked to design a photo-sharing app for 50 million daily users. She knew the method from lesson 1.3. But with Meera watching and the clock running, she wrote:
50M × 10 photos viewed/day = 500M/day
500M ÷ 86,400 = …and then spent nearly two minutes on long division, got 5,787.0something, lost her train of thought, and forgot to estimate storage at all.
Meera's advice afterwards: "Nobody cares about the 787. Say 'about 6,000 a second,' and move on to what it means."
Estimation in an interview isn't about precision. It's about getting to the right order of magnitude fast, and saying what it means for the design. That needs two things: a handful of numbers you know without thinking, and a few templates you can apply in seconds.
Step 2 of 8 · 1 min
Numbers to know by heart
Time
- Seconds in a day: ~100,000 (really 86,400; rounding up 15% never changes a design).
- Seconds in a month: ~2.5 million. In a year: ~30 million.
- Peak vs average: 2–3× for most apps, 10× or more around events.
So:
| Per day | ≈ per second |
|---|---|
| 1 million | 10 |
| 10 million | 100 |
| 100 million | 1,000 |
| 1 billion | 10,000 |
Sizes
- Thousand, million, billion, trillion ≈ KB, MB, GB, TB. 1 million items of 1 KB = 1 GB. 1 billion items of 1 KB = 1 TB.
- Bits vs bytes: 8×. Network speeds are in bits. 1 Gbps ≈ 125 MB/s.
Typical sizes of common things:
| Thing | Rough size |
|---|---|
| A short text post or message, with metadata | 0.5–1 KB |
| A user profile row | 1 KB |
| An ID | 8–16 bytes |
| A photo, compressed for a phone feed | 100–300 KB |
| A photo, original from a phone | 2–5 MB |
| A minute of video at 480p / 1080p | ~10 MB / ~40 MB |
| A minute of audio | ~1 MB |
Latency (from lesson 1.2)
| Operation | Rough time |
|---|---|
| Memory read | ~100 ns |
| SSD random read | ~0.1 ms |
| Round trip in a data center | ~0.5 ms |
| Round trip across a continent | ~60 ms |
| Round trip between continents | ~150–200 ms |
Capacity rules of thumb
These are deliberately rough and conservative. Real numbers vary a lot, but in an interview, a reasonable order of magnitude is what matters:
| Component | Handles roughly |
|---|---|
| One app server, simple JSON API | 1,000–10,000 requests/s |
| One relational database (good hardware, simple queries) | thousands to ~10,000 writes/s; more reads, especially from memory |
| One Redis node, simple operations | ~100,000 operations/s |
| One Kafka partition | ~10 MB/s or more |
| One WebSocket gateway server | ~100,000 connections |
When an estimate lands near one of these limits, that's the moment the design needs another tool: replicas, a cache, sharding, a queue.
Step 3 of 8 · 1 min
Templates
Most estimates follow one of a few patterns. Practise them until they're automatic.
Requests per second
daily users × actions per user per day ÷ 100,000 = average per second
× 2 or 3 = peak per second50M users × 10 feed loads ÷ 100,000 = 5,000/s average, ~15,000/s at peak.
Storage
new items per day × size per item × 365 = per year
× 3 for replicas and backups (if relevant)1M photos a day × 2 MB = 2 TB a day, about 700 TB a year, before replicas.
Bandwidth
views per day × size per view ÷ 100,000 = bytes per second
× 8 = bits per second500M photo views × 200 KB = 100 TB a day ÷ 100,000 ≈ 1 GB/s ≈ 8 Gbps average.
Memory for a cache
hot items × size per itemThe 20% of profiles that get most reads: 10M × 1 KB = 10 GB. Fits in one large cache node, or a few small ones.
Servers needed
peak requests per second ÷ per-server capacity (at ~60% busy) + spares15,000 requests/s ÷ (2,000 × 0.6) ≈ 12.5, so about 13 servers, plus a few spares across zones.
Step 4 of 8 · 1 min
Doing the arithmetic in your head
Powers of ten
Write every number as "a few × 10ⁿ," multiply the front parts, add the exponents:
50M × 200 KB = 5×10⁷ × 2×10⁵ bytes = 10 × 10¹² = 10¹³ bytes = 10 TBRound to friendly numbers
Round as you go: 86,400 becomes 100,000; 3.7 becomes 4; 1,024 becomes 1,000. Say you're doing it ("call that 4"). Errors of 20% or 30% never change a design. What changes a design is a factor of 10 or 100, and rounding can't hide that.
Keep units with every number
Write "GB/day" or "req/s" next to every number. The two most common estimation mistakes are dropping a "per second" versus "per day" conversion and confusing bits with bytes. Units on paper catch both.
Sanity-check the result
Once you have a number, compare it with something you know. "10 TB a day of photo traffic for 50 million users is 200 KB each, about one photo per person per day." Too low for a photo app, so check whether the assumptions are reasonable. A quick check like this catches a dropped factor of 1,000 before it ends up in your design.
Step 5 of 8 · 1 min
Saying what it means
An estimate without a conclusion is wasted time. Always finish with the design consequence:
- "About 6 writes a second: one database handles that easily, so no sharding."
- "About 50,000 writes a second, more than one database is comfortable with. We'll need to partition, or put a queue in front and batch."
- "8 Gbps of photo traffic: this is a CDN problem more than a server problem."
- "10 GB of hot data: one cache node fits it; I'll use a small cluster for availability."
This is what interviewers actually listen for. Getting 5,787 is worth nothing; getting "about 6,000, so one database, plus replicas for reads" is worth a lot.
Step 6 of 8 · 1 min
From the real world: numbers to calibrate against
An estimate is only useful if you can tell whether it's plausible. "We need 50,000 requests a second" might be normal or absurd, depending on the product. One way to build that sense is to remember a handful of figures real companies have published. Every one below appears, with its source, somewhere in this course.
- Twitter, around 2012: about 300,000 timeline reads a second, against several thousand tweets a second (lesson 4.4). A huge, mature social network at the time.
- WhatsApp, 2012: over 2 million open connections on one well-tuned server (lesson 7.1). So "millions of connected users" doesn't mean thousands of machines.
- Hotstar, 2019: 25.3 million people watching one live match at the same moment (lesson 7.4).
- GitHub, 2018: a DDoS attack at 126.9 million packets a second, 1.35 terabits per second (lesson 6.3). That's what "can't be handled by your own servers" looks like.
- Roblox, 2021: its caching tier handled about a billion requests a second in normal operation (lesson 6.4).
How to use them in an interview:
- As anchors, not targets. If your estimate for a new startup's feature exceeds Twitter's 2012 timeline traffic, recheck your assumptions out loud.
- To size servers per tier. If one well-tuned gateway holds hundreds of thousands to millions of connections, then 10 million connected users is tens of gateways, not thousands.
- To show judgement. "That's about the scale of Twitter's timelines a decade ago, so precomputed feeds make sense" is the kind of sentence that tells an interviewer you have a feel for numbers, not just a formula.
Step 7 of 8 · 2 min
Drills
Practise these against a timer, aiming for about 90 seconds each, including the conclusion. Then check your work against the answers.
1. A messaging app has 50M daily users, each sending 40 messages a day. Messages per second at a 3× peak? Storage per year at 300 bytes per message?
50M × 40 = 2B a day ÷ 100,000 = 20,000/s average, ~60,000/s at peak. Storage: 2B × 300 B = 600 GB a day, about 220 TB a year before replication. Conclusion: a distributed store partitioned by conversation (lesson 7.1).
2. A URL shortener creates 100M new links a month and serves 10B redirects a month. Writes and reads per second? How many characters are needed in the short code to last 10 years?
Writes: 100M ÷ 2.5M s ≈ 40/s. Reads: 10B ÷ 2.5M ≈ 4,000/s average, perhaps 10,000 at peak. Over 10 years, 100M × 120 = 12B links. With 62 possible characters (a–z, A–Z, 0–9), 62⁶ ≈ 57B, so 6 characters suffice; 7 gives plenty of room (about 3.5 trillion). Conclusion: read-heavy, so cache hot links and serve redirects from the edge (lesson 8.4).
3. A video app gets 1M uploads a day, averaging 2 minutes, stored in five rungs totalling about 60 MB per minute. Storage per year?
1M × 2 min × 60 MB = 120 TB a day, about 44 PB a year. Conclusion: storage tiers and lifecycle policies matter as much as compute (lesson 7.4).
4. A ride app has 300,000 drivers online at peak, each sending a location every 3 seconds, about 100 bytes each. Updates per second, and bandwidth?
300,000 ÷ 3 = 100,000 updates/s. × 100 B = 10 MB/s, about 80 Mbps. Conclusion: the bandwidth is trivial; the problem is 100,000 writes a second, so keep positions in memory and partition by city (lesson 7.2).
5. A cache must hold the profiles of the 30M most active users at 2 KB each, with one replica. How much memory, and roughly how many 64 GB nodes?
30M × 2 KB = 60 GB, × 2 for the replica = 120 GB. With headroom (aim to fill nodes to about 60–70%), that's about 3 nodes of 64 GB per copy, or 5 to 6 nodes in total. Conclusion: a small cache cluster.
Step 8 of 8 · 1 min
Further reading
- Jeff Dean's "Numbers Everyone Should Know" talk slides, the source of many latency tables.
- Lesson 1.3 in this course, for the full method with Chirp's worked example.
- Your cloud provider's instance and pricing pages, for current real numbers to check your rules of thumb against.