Load Estimation Basics

Estimation starts with assumptions

In a real project, exact numbers are often unknown in advance. In an interview, they may be completely absent from the prompt. That does not stop the design process: we state reasonable assumptions explicitly, calculate from them, and recalculate the model later if the inputs change.

For a photo service, for example, we can assume the number of daily active users, the average number of uploads per user, and the average photo size. That is already enough to produce first estimates for request volume and storage.

DAU = 10,000,000
uploads_per_user_per_day = 2
average_object_size = 2 MB

Start with product quantities, then derive technical ones

Inputs usually arrive in product terms: active users, messages per day, views, uploaded files, or retention period. For architecture work, these need to be converted into quantities that describe load on the system.

• operations per day become requests per second;
• object count and object size become storage volume;
• request frequency and response size become network traffic;
• average values are supplemented with a peak-load estimate.

Do not calculate everything just because you can. Estimate only the quantities that help answer an architecture question. If data size has no effect on the decision being discussed, there is no reason to spend time on a detailed storage model.

Keep track of units

Most mistakes in quick calculations come not from the arithmetic itself, but from mixing units. Seconds get confused with days, bytes with bits, and megabytes with megabits. That is why it is useful to write units directly into the formula.

requests/day ÷ 86,400 s/day = requests/s
objects/day × bytes/object = bytes/day
requests/s × bytes/request = bytes/s

Units act as a built-in check: if cancelling them leaves the quantity we intended to measure, the formula is probably structured correctly.

Rounding is more useful than false precision

In System Design, the order of magnitude is usually more important than a number with four decimal places. If the result is 1,973 requests per second, it is usually better to continue with roughly 2,000 RPS. The model stays readable, and accidental precision does not create the illusion that the inputs were known perfectly.

It is also useful to separate a fact from an assumption. If the prompt says “20 million daily active users,” that is an input. If we decide that each user performs three reads on average, that is our assumption and should be stated explicitly.