Back-of-the-Envelope Estimation

Numbers decide architecture. A service with 50 writes per second fits on one well-tuned relational database; one with 500,000 writes per second needs partitioning, batching and probably a log-structured store. Without a quick estimate you cannot tell which world you are in, so you either over-engineer a simple system or under-build one that will fall over. Interviewers use estimation to see whether you can reason quantitatively under uncertainty.

The output should be a handful of numbers that drive decisions: average and peak QPS, read/write ratio, bytes stored per day and over the retention period, network bandwidth, and how many servers or how much memory that implies. Every number should trace back to a stated assumption so it can be revised when the interviewer changes a parameter.

Storage and memory are counted in powers of two, and the useful trick is that each step of 2^10 is roughly a factor of a thousand. That lets you move between bits, kilobytes and petabytes without a calculator. Remember also the sizes of common things: an ASCII character is one byte, a 64-bit integer or timestamp is 8 bytes, a UUID is 16 bytes, a short text post is a few hundred bytes, a compressed photo is a few hundred kilobytes, and a minute of HD video is tens of megabytes.

A classic table popularized by Jeff Dean lists the cost of common operations. The exact values have drifted as hardware improved, but the ratios still teach the important lessons. Memory is fast and disk seeks are slow; avoid random disk access where possible. Simple compression is cheap relative to sending bytes across a wide-area network, so compress before shipping data between regions. Round trips between continents cost on the order of 150 ms, which is why multi-region systems avoid synchronous cross-region calls on the hot path.

The practical use of this table is to sanity-check designs. If a page requires ten sequential cross-region calls, you already know it cannot load in under a second. If a lookup needs a random disk read per request at 10,000 QPS, you know a cache or SSDs are needed.

Availability is the fraction of time a service is operational, usually quoted in nines. Cloud providers publish SLAs (service level agreements) that commit to a level such as 99.9% or 99.99% and give credits when they miss. Each additional nine cuts allowed downtime by a factor of ten, and the engineering cost to get there rises steeply because you must eliminate ever rarer failure modes.

Two composition rules matter. Components in series multiply: if a request touches three services each at 99.9%, the whole path is about 0.999^3 ≈ 99.7%. Components in parallel (redundant replicas) combine as one minus the product of failure probabilities: two independent 99% replicas give 1 - 0.01 x 0.01 = 99.99%. This is the quantitative argument for redundancy.

Assume 100 million DAU. Each user uploads 0.5 photos per day, so uploads are 50 million per day. Dividing by 86,400 gives about 580 write QPS; with a 3x peak factor, roughly 1,750. Each user views 50 photos per day, giving 5 billion views per day, or about 58,000 read QPS on average. The read:write ratio is 100:1, which immediately suggests heavy caching and a CDN for image bytes.

For storage, assume an average photo of 500 KB after compression. Daily new storage is 50 million x 0.5 MB = 25 TB per day. Over a year that is 25 x 365 ≈ 9,125 TB, about 9 PB, and with three-way replication roughly 27 PB per year. Egress bandwidth for views is 5 billion x 0.5 MB = 2.5 PB per day, about 29 GB/s on average, a number that only a CDN can absorb economically. Metadata, by contrast, is tiny: 50 million rows x 200 bytes is 10 GB per day.

Round aggressively. Treat 86,400 seconds as 100,000 and 99,987 / 9.1 as 100,000 / 10. The point is to keep arithmetic simple enough to do in your head while talking, and the rounding error is far smaller than the uncertainty in your assumptions anyway.

Write assumptions down where the interviewer can see them, and label every unit. Writing 5 next to storage is meaningless; 5 TB per day is not. Separate averages from peaks, and state the peak factor you chose. Common things to estimate are QPS, peak QPS, storage, cache size, bandwidth and number of servers; practice each until it takes under a minute.

Estimates are only valuable if they change the design. A write QPS under a few thousand usually means a single primary database is fine. Hundreds of terabytes per year means object storage rather than database blobs. A working set that fits in tens of gigabytes means one cache cluster can serve it from RAM. Bandwidth in gigabytes per second means a CDN is mandatory, not optional.

Close the loop out loud: state the number, then state the consequence. For example, 58,000 read QPS with a 100:1 ratio means we cache feeds and serve images from a CDN; 9 PB a year means blob storage with lifecycle policies to cold tiers. This is what interviewers mean when they say a candidate reasons with data.