Skip to main content
Estimation Rules of Thumblesson 3 of 3 · 3 min read

Sanity Checks That Catch Bad Numbers

Estimates go wrong silently

Estimates go wrong silently, so run checks the way pilots run checklists.

Comparing against a system you know is the first check. Twitter historically saw around 500 million posts a day, about 6,000 a second. Google handles on the order of 100,000 searches a second. If your niche recipe app lands above Twitter's write volume, the error is in your envelope and not in the world. Keep three or four public anchors and rank every answer against them.

Units come next, because unit errors are the most common and the most embarrassing. Bits against bytes is a factor of eight, and it bites exactly where people forget it: network links are quoted in bits and payloads in bytes. Per day against per second is a factor of about 100,000. Milliseconds against microseconds is a thousand.

Anything surprising is worth re-deriving with the units written out. A hundred megabytes a second times eight is 800 megabits, which is nearly a full gigabit link.

The absurd hardware test

The absurd hardware test comes third. Convert your answer into machines and react to the picture. A mid-size startup design implying 4,000 database servers or a petabyte of memory is wrong somewhere upstream. The reverse informs you too: if the arithmetic says a third of a server, your honest architecture is one machine and a backup, whatever the diagram fashion says.

Computing one quantity two ways catches the rest. Storage from write rate times record size times retention should roughly match storage from user count times data per user. When both paths land within a factor of two or three, trust the number. When they differ by a hundred, one of your assumptions is broken and you have just found which conversation to have.

Error bars stay attached. Round to one significant figure while working, and present the result as about 3 terabytes a year, good to within a factor of two or three. Precision you do not have is how bad numbers survive review.

Worked example

At a logistics startup, Noor's teammate presents a plan for GPS tracking: 100,000 trucks reporting once a second, a claimed 90 TB of data a day, and a 20-node Cassandra cluster to hold it. Noor runs the two-path check at the whiteboard. A position report is latitude, longitude, truck ID, and a timestamp, about 100 bytes in a binary encoding. 100,000 reports a second times 100 bytes is 10 MB per second, about 860 GB a day, roughly 100 times less than the slide. The gap traces to the assumption: the 90 TB figure used 10 KB per record, the size of the full JSON payload with HTTP headers, which nobody intended to store. At 860 GB a day the plan shrinks to a partitioned Postgres, its relational database, with Kafka absorbing the 100,000 writes per second of ingest. One cross-check deleted 17 servers.

Estimation Rules of Thumb: wrapping up

In the real world

  • 01Jeff Dean's Google talks on building large systems explicitly instruct engineers to do back-of-envelope calculations before choosing designs, which is where the interview tradition comes from.
  • 02The technique is named for physicist Enrico Fermi, who estimated the Trinity test's yield within a useful factor by dropping paper scraps into the blast wave, the original demonstration that rough inputs give decision-grade outputs.
  • 03Twitter's engineering blog documented the 2013 record of 143,199 tweets per second during a Japanese TV airing of Castle in the Sky, roughly 24 times their average rate, a public data point for how far peaks stray from means.
  • 04WhatsApp served about 450 million users with roughly 32 engineers at acquisition, with published benchmarks of over 2 million TCP connections on a single FreeBSD server, an anchor for what one machine can hold.
  • 05Public estimates put Google Search at around 100,000 queries per second, one of the most useful upper-bound anchors for ranking your own traffic estimates.

Questions people ask

How precise should a back-of-envelope estimate be?

Within a factor of 2 or 3. The purpose is choosing between architectures that differ by orders of magnitude, so chasing precision past one significant figure wastes interview time and signals that you don't know what the number is for. Round aggressively, state the error bars, and spend the saved minutes on the decision the number drives.

What if I don't know a number the estimate needs?

State an assumption and keep moving: 'assume 1 KB per message' or 'assume 10 percent of users post daily.' Interviewers care whether your reasoning is sound given the inputs, and most will correct an assumption if it matters. A stated guess is recoverable; a stalled candidate or a silently buried guess is not.

Which numbers are actually worth memorizing?

About a dozen: seconds in a day (86,400, round to 100,000) and a year (31.5 million), the users-to-bytes anchors (1 million users at 1 KB is 1 GB), a few object sizes (tweet 280 bytes, photo 300 KB, web page 2 MB), and single-machine ceilings (web server 10,000 requests per second, Postgres 5,000 writes, Redis 100,000 ops). Everything else derives from those.

Quick review

QPS formula:
DAU × requests_per_user_per_day ÷ 86,400. Multiply by 2 to 5× for peak
Storage formula:
QPS × record_size × seconds_per_year. 100 QPS × 1 KB × 31.5M sec = 3 TB/year
1M users × 1 KB/user = 1 GB. 1B users × 1 KB/user = 1 TB. Easy mental math
Bandwidth:
QPS × avg_response_size. 1000 req/s × 100 KB = 100 MB/s = 800 Mbps
Server count:
total QPS ÷ single_server_RPS. 100k QPS ÷ 10k per server = 10 servers
80/20 rule:
80% of reads hit 20% of data → cache the top 20% and you handle most traffic
Compression:
gzip achieves 5 to 10× on JSON/HTML. Factor into bandwidth calculations
in the room

Back-of-envelope in every interview. State assumptions explicitly, show formula, then compute. Round aggressively.