Estimating scale with back-of-envelope numbers

Turn "a lot of users" into requests, storage and bandwidth.

Before choosing any part, you need to know how big the problem is. Do we need one server or fifty? Terabytes or gigabytes? You will not get exact answers, and you don't need to. A back-of-envelope estimate gets you within a factor of two or three using round numbers, and that is enough to tell a single database from a sharded fleet.

Two facts make the arithmetic easy. A day has 86,400 seconds, which we round to about 100,000 (10 to the 5th). And a million requests per day is therefore roughly 10 requests per second. Add the habit of designing for peak rather than average: traffic is rarely flat, so multiply the average by 2 to 5 depending on how spiky the app is. Dinner time in a food-delivery app is very spiky.

orders/day        = 2,000,000
avg orders/sec    = 2,000,000 / 86,400  ~= 23
peak (x5)         ~= 115 writes/sec
reads/day         = 2,000,000 x 30      = 60,000,000
peak reads/sec    ~= 3,500
storage/year      = 4 GB x 365          ~= 1.5 TB
peak bandwidth    = 3,500 x 5 KB        ~= 17.5 MB/s (~140 Mbps)

Look at what the numbers told us: the read load is roughly thirty times the write load, so reads, not writes, will shape the design. That is the real payoff. Estimating is less about the numbers themselves than about discovering which side is heavy, how fast storage grows and where the first bottleneck will appear.