Numbers to Memorize for System Design

Back-of-envelope estimation is a critical skill in system design interviews because it transforms vague requirements into concrete engineering decisions. When someone says '100 million daily active users,' you need to instantly translate that into queries per second, storage per year, and bandwidth requirements. The difference between a system that needs one database server and one that needs a hundred is entirely determined by these numbers. Interviewers are not looking for exact precision -- they are evaluating whether you can reason quantitatively about system scale.

The foundation is the power-of-two table. Every system design candidate should know: 2^10 is approximately 1 thousand (1 KB), 2^20 is approximately 1 million (1 MB), 2^30 is approximately 1 billion (1 GB), and 2^40 is approximately 1 trillion (1 TB). These approximations let you quickly convert between units and estimate orders of magnitude. When someone says '1 billion records at 1 KB each,' you instantly know that is 1 TB of storage. Time unit conversions are equally important: there are 86,400 seconds in a day (approximately 100,000 for estimation), 2.5 million seconds in a month, and 30 million seconds in a year.

Typical data sizes anchor your storage estimates. A tweet or text message is roughly 140 bytes. A typical JSON API response is 1-10 KB. A smartphone photo is 500 KB to 5 MB. A minute of standard video is about 50 MB. A minute of 4K video is about 350 MB. For throughput, a single modern server can handle 10,000 to 100,000 simple QPS depending on the workload (10K for database-backed requests, 100K for in-memory cache hits). A single MySQL instance handles roughly 10,000-30,000 simple queries per second. Redis handles 100,000+ operations per second. These benchmarks tell you when you need horizontal scaling.

The real power comes from chaining estimates. Consider this example: '100M DAU, 10% are daily active writers, each writes 2 tweets per day.' The chain goes: 100M * 10% = 10M writers/day, 10M * 2 = 20M writes/day, 20M / 100K seconds = 200 writes/sec. A single MySQL instance can handle 200 writes/sec easily -- no sharding needed for writes. For reads: if each user reads 50 tweets/day, that is 5B reads/day or 50,000 reads/sec -- one instance is tight, so add read replicas or a cache. Storage: 20M tweets/day * 140 bytes = 2.8 GB/day, about 1 TB/year -- one disk handles this. This chain from DAU to infrastructure requirements is the core skill interviewers test.

Estimation in system design is like estimating your grocery budget. You do not need to know the exact price of every item -- you need to know that produce is roughly $3/lb, meat is $8/lb, and cereal is $4/box. With those anchors, you can estimate a cart of 20 items within reasonable accuracy: 'About $80-100.' Similarly, in system design, you anchor on known data sizes (tweet is 140 bytes, photo is 500KB) and throughput benchmarks (MySQL handles 10K QPS) and chain them to estimate infrastructure needs. The interviewer does not expect $87.43 -- they expect you to know it is not $10 and not $1,000.