Back-of-the-Envelope Estimation, Step by Step

The numbers you need to remember

Powers of two (data sizes):

Handy shortcut: 2^10 ≈ 1,000, so 2^20 ≈ 1 million, 2^30 ≈ 1 billion, 2^40 ≈ 1 trillion.

Time conversions:

So 1 million requests per day ≈ 12 requests per second on average. Remember that one; it's very useful.

Latency numbers (rough orders of magnitude):

Latency is the time one operation takes, from start to finish. ns means nanosecond (one billionth of a second), µs means microsecond (one millionth) and ms means millisecond (one thousandth). A data centre is a building full of servers. Exact numbers change with hardware. What matters are the big lessons:

• Memory is much faster than disk. That's why caches exist. A cache is a small, fast store that keeps a copy of data you read often, so you do not fetch it from the slow place each time.
• SSDs are much faster than spinning disks, especially for random reads.
• The network inside a data centre is fast. Across continents it's slow, and the speed of light won't improve.
• Reading data sequentially is much faster than jumping around. Sequential means one piece after the next, in order. Random means jumping to different places.
• Avoid unnecessary network round trips, especially long-distance ones.

Rough capacity anchors (very workload-dependent):

• One well-tuned app server: roughly hundreds to a few thousand simple requests per second.
• One relational database (a database that stores data in tables, such as PostgreSQL or MySQL) on good hardware: often thousands to tens of thousands of simple queries per second.
• One Redis instance (Redis is a very fast database that keeps its data in memory; people often use it as a cache): often tens of thousands to 100,000+ simple operations per second.

Treat these as starting guesses, not facts. Real numbers depend heavily on what each request does, so measure your own system when it matters.

The estimation recipe

Most estimates follow the same steps:

Average QPS is the number of requests per second over a whole day. Peak QPS is the number in the busiest moment. Two formulas do most of the work:

Average QPS = requests per day ÷ 86,400   (≈ ÷ 100,000)Peak QPS    = average QPS × 2 to 10       (depends on how "spiky" traffic is)

A social app with an evening rush might use ×3. A ticket sale that opens at exactly 10:00 AM might need ×50 or more.

Worked example: a photo-sharing app

Let's estimate for an Instagram-like app. We write our assumptions first:

• 10 million daily active users (DAU).
• Each user views 50 photos per day.
• 1 in 5 users uploads one photo per day (0.2 uploads per user).
• Average original photo size: 2 MB.
• Photos are shown in the feed as a resized ~200 KB version.
• Each photo has about 1 KB of metadata (owner, caption, time, location).
• Peak traffic = 3× average.
• Keep photos forever. Plan for 5 years.

Step 1: Traffic (QPS)

Reads (photo views):

10M users × 50 views = 500 million views/day500M ÷ 100,000 ≈ 5,000 reads/second (average)Peak ≈ 5,000 × 3 = 15,000 reads/second

(With the exact 86,400, it's about 5,800 average and 17,000 peak. Close enough.)

Writes (uploads):

10M × 0.2 = 2 million uploads/day2M ÷ 100,000 = 20 uploads/second (average)Peak ≈ 60 uploads/second

Insight: the ratio is 250 reads for every write. This is a very read-heavy system, so we should design for fast reads. We use caching, CDNs and read replicas. A CDN (content delivery network) is a group of servers around the world that keep copies of files close to users. A read replica is a copy of a database that only answers read requests.

Step 2: Storage

Photos:

2M uploads/day × 2 MB = 4 TB per day4 TB × 365 ≈ 1.5 PB per year5 years ≈ 7.5 PB

Plus resized versions (thumbnails and feed-size images), say another 20%, so about 9 PB over 5 years.

Insight: this is far too much for database servers, so photos go in object storage. Object storage (like Amazon S3) is a service that stores files as separate objects and scales to huge sizes. It also keeps several copies of your data so it is not lost (this is called durability). So we don't need to multiply by the replication factor ourselves here.

Metadata:

2M photos/day × 1 KB = 2 GB per day× 365 ≈ 730 GB per year5 years ≈ 3.7 TB

Insight: metadata is small. A single well-configured relational database with replicas can hold this for years. To shard means to split one big database into smaller parts, each on its own server. We don't need to shard on day one, but we should plan for it.

Step 3: Bandwidth

Bandwidth is how much data moves through a network link each second. Gbps means gigabits per second. Outgoing data is also called egress. Outgoing (serving feed photos):

500M views/day × 200 KB = 100 TB per day100 TB ÷ 86,400 s ≈ 1.2 GB per second ≈ ~10 Gbps averagePeak ≈ 30 Gbps

Incoming (uploads):

4 TB/day ÷ 86,400 ≈ 46 MB/s ≈ ~0.4 Gbps average

Insight: ~10–30 Gbps of image traffic is a strong signal to use a CDN. You don't want all of that coming from your own servers. It also shows why resizing images matters. Serving the original 2 MB file instead of 200 KB would mean 10× more bandwidth and a much bigger bill.

Step 4: Cache (memory)

A common rule is the 80/20 rule: about 20% of the content gets 80% of the views. So let's cache metadata for the "hot" 20% of daily reads:

500M reads/day × 1 KB metadata = 500 GB of metadata read per dayCache 20% ≈ 100 GB

Insight: 100 GB fits comfortably in a small Redis cluster, a few nodes with plenty of RAM. The photos themselves are cached by the CDN, not by Redis.

Step 5: Number of servers

Assume one app server can handle about 1,000 requests per second for these simple API calls:

Peak 15,000–17,000 QPS ÷ 1,000 ≈ 15–17 serversAdd headroom (run ~60–70% busy) and room for one zone failing → ~25–30 servers

Insight: this is a horizontally scaled, stateless app tier (post 7). "Horizontally scaled" means we add more servers instead of buying a bigger one. "Stateless" means a server keeps no user data between requests, so any server can answer any request. Tens of servers is very manageable, so we don't need anything unusual.

The summary you'd write on a whiteboard:

In about ten minutes, we've gone from "a photo app" to concrete decisions about storage type, CDN, cache size and server count.

Tips for good estimates

• Write assumptions down and say them out loud. If someone says "users upload more like 1 photo a day", you just multiply by 5.
• Round to easy numbers. 86,400 becomes 100,000; 2.6 million becomes 2.5 million. Your answer will be within about 20%, which is fine.
• Use scientific notation for big numbers. 5 × 10^8 is easier to multiply than 500,000,000.
• Keep units attached. Mixing up bits and bytes (Gbps vs GB/s) is a common 8× mistake: 1 byte is 8 bits, so 1 GB/s ≈ 8 Gbps.
• Sanity-check the result. "10 PB for a small startup?" If it looks odd, recheck your assumptions.
• Use estimates to make decisions, not to show off maths. Always finish with "so this means…".
• Separate reads and writes. They usually lead to different design choices.
• Don't forget peaks. Systems fail at peak, not on average.

Common mistakes

• Using average QPS to size servers and forgetting peak traffic.
• Forgetting that data accumulates over years.
• Ignoring metadata vs media differences: one is small and structured, the other huge and unstructured.
• Spending 20 minutes on precise arithmetic. Precision doesn't matter here; direction does.
• Treating capacity anchors (like "1,000 requests per server") as facts instead of assumptions.