Back-of-envelope estimation cheat sheet

The full lesson, with a worked dinner-rush example: Latency and estimation. Timings for memory, disks and networks are in the latency numbers cheat sheet.

The goal is the right order of magnitude, fast, with assumptions said out loud. "Two servers, not twenty" is the answer you need; 3.47 servers is not.

The method in one picture

1. Users: daily active users.
2. Actions: actions per user per day, split into reads and writes.
3. Average rate: actions a day ÷ 1 lakh seconds.
4. Peak: average × a stated peak factor.
5. Storage: new items a day × size × days kept × copies.
6. Bandwidth: rate × size of each response.
7. Servers: peak ÷ what one server handles comfortably, plus spare.

Handy numbers

Time

• Seconds in a day: 86,400; call it 1 lakh (10⁵).
• Seconds in a month: about 25 lakh (2.5 million).
• Seconds in a year: about 3 crore (30 million).

Indian and international units

• 1 lakh = 100,000 = 10⁵.
• 10 lakh = 1 million = 10⁶.
• 1 crore = 10 million = 10⁷.
• 100 crore = 1 billion = 10⁹.
• 1 lakh crore = 1 trillion = 10¹².

Sizes (each step is about 1,000×)

• 1 KB = 1,000 bytes: a short text message with its details.
• 1 MB = 1,000 KB: a phone photo or two after compression.
• 1 GB = 1,000 MB: a film.
• 1 TB = 1,000 GB: a thousand films.
• 1 PB = 1,000 TB.
• Shortcuts: 1 KB × 10 lakh = 1 GB. 1 KB × 100 crore = 1 TB. 1 MB × 10 lakh = 1 TB.

Rates from daily counts

• 1 lakh a day ≈ 1 a second.
• 10 lakh a day ≈ 10 a second.
• 1 crore a day ≈ 100 a second (really about 115).
• 100 crore a day ≈ 10,000 a second.

Typical sizes

Illustrative; say yours out loud.

• ID or timestamp: 8 bytes. UUID: 16 bytes.
• English character: 1 byte. Hindi character in UTF-8: about 3 bytes.
• Chat message with its details: about 100–500 bytes.
• Database row for a user, order or link: about 0.5–1 KB.
• Web page's HTML: about 100 KB; about 20–25 KB compressed.
• Phone photo: about 2 MB. Thumbnail: about 20–50 KB.
• HD video: about 2–5 Mbps, so roughly 15–40 MB a minute.
• Voice call: tens of kbps.

Traffic

Formula: daily active users × actions per user per day ÷ 1 lakh = average requests a second.

• Peak factor: plan for 2–5× the average from daily rhythm (lunch, dinner, evenings).
• Events: a cricket final or a midnight sale can be 10–20× or more. A shop that sees 300 a second normally might see 6,000 in the first minutes of a sale. Estimate events separately.
• Read-to-write ratio: split them. Social feeds and link shorteners are often 100 reads to 1 write; chat is closer to 1 to 1; logging is almost all writes.

Example: 2 crore daily users × 10 page views = 20 crore a day ÷ 1 lakh = 2,000 a second average; at 3–5×, about 6,000–10,000 at peak.

Storage

Formula: new items a day × size × days kept × copies, plus extras, plus growth.

• Copies: the replication factor is often 3.
• Extras: thumbnails and resized versions, indexes (say 10–30% on top), backups.
• Growth: add 30–50% a year if the product is growing.

Example, a photo app:

• 20 lakh uploads a day × 2 MB = 40 lakh MB = 4 TB a day.
• × 365 ≈ 1,500 TB = 1.5 PB a year for the originals alone.
• Real figure with 3 copies, four resized versions and backups: closer to 15 TB a day.
• Conclusion: this needs object storage, not a database disk.

Example, posts: 50 lakh posts a day × 1 KB × 365 × 3 copies ≈ 5.5 TB a year, before images. Small: a few database machines.

Bandwidth

Formula: requests a second × response size. Then × 8 for bits.

• Bits vs bytes: a 100 Mbps link carries about 12.5 MB a second.
• Example: 2,000 a second × 100 KB pages = 200 MB a second ≈ 1.6 Gbps out. Images belong on a CDN.
• Example: the photo app's 4 TB a day viewed 10 times each = 40 TB a day out ÷ 1 lakh seconds ≈ 400 MB a second ≈ 3.2 Gbps average, more at peak. The bandwidth bill can beat the storage bill.
• Uploads vs downloads: size them separately; downloads usually dominate.

Servers and machines

Formula: peak requests a second ÷ what one server handles at a comfortable load, rounded up, plus at least one spare.

• Comfortable load: run at 50–70% utilisation at the peak, not 100%. Queues explode near full.
• Spare: N+1 at least, so one crash doesn't overload the rest; N+2 or a spare zone for critical systems.
• Example: 600 a second at dinner, one server handles about 200 flat out. Three would be exactly full; run four, each at about 150.

Per-machine figures (say, to be measured on real hardware):

• App server, simple requests: a few hundred to a few thousand a second.
• In-memory cache node: about a lakh of simple operations a second.
• Database primary: a few thousand to tens of thousands of simple writes a second; more for reads with good indexes.
• Storage node in a distributed store: about 20,000 operations a second and about 1 TB of live data on a 2 TB SSD.
• Web crawler fetch: about 1 second each, mostly waiting, so hundreds open at once per machine.

Little's law for pools: requests in flight = rate × time each takes.

• 600 a second × 0.2 seconds = 120 in flight: size thread pools and connection pools for that, plus headroom.
• Same rate at 2 seconds each = 1,200 in flight. A slow dependency fills every pool.

Caches

• Hit rate saves the database: at 250 reads a second and a 90% hit rate, the database sees only 25 a second.
• Cache size: often the hottest 10–20% of data covers most reads. 10 TB of data, 20% hot = 2 TB of memory, spread over many nodes.
• Miss storm: if the cache empties, the database sees the full 250. Check it can survive that, or warm the cache first.

Worked example: food app menus

From the lesson:

• 50 lakh menu views a day ÷ 1 lakh = 50 a second average.
• Dinner peak at 5× = 250 a second.
• One server handles about 100 comfortably: 250 needs three; add a spare = 4 servers.
• 90% from the cache: 25 database reads a second at peak.
• 250 × 60 KB = 15 MB a second out.

Worked example: a chat app

• Users: 10 crore daily users × 40 messages = 400 crore messages a day.
• Average: 400 crore ÷ 1 lakh = 40,000 messages a second.
• Peak: 3× = 1.2 lakh a second (festival greetings at midnight can be far higher).
• Storage: 400 crore × 200 bytes = 800 GB a day; × 3 copies = 2.4 TB a day ≈ 900 TB a year. Needs sharding.
• Connections: if a third of daily users are online at peak, about 3 crore open connections; at, say, 1 lakh per server, 300 connection servers plus spare.
• Write path: 1.2 lakh writes a second × 3 copies = 3.6 lakh storage operations a second. At about 20,000 per node that is 18 nodes flat out; at a 60% target, about 30 nodes.

Sanity checks

• Compare with something known: does your answer imply every Indian uses the app 50 times a day? A film downloads in seconds at home?
• Units on every line: MB vs Mb, per day vs per second.
• Did you count copies, indexes and backups? Forgetting them is the most common storage miss.
• Did you size for the peak, not the average?
• Round to one or two significant figures. Spend time on the factors that change the design (peak factor, read-to-write ratio), not on decimals.

Saying it in an interview

• "Let's assume 10 crore daily users, 20 actions each: 200 crore a day, about 20,000 a second, say 60,000 at peak."
• "Reads are 10× writes, so 6,000 writes a second at peak. That's near the limit of one database primary, with no room to grow, so I'll shard or use a store that spreads writes."
• "Each item is about 1 KB, kept 5 years with 3 copies: 200 crore × 1 KB × 1,800 days × 3 ≈ 10 PB. That's object storage or a big distributed store."
• Then move on. The estimate exists to justify the design choices that follow.