Clients ask "will it scale" long before there is anything to point a load generator at. The honest answer is a set of assumptions written down, not a number, and treating it as a number is how projects get expensive infrastructure they never needed.
Start with the traffic shape, not the total
Total requests per day tells you almost nothing. What matters is the shape: is demand flat, or does it arrive in a burst at a known time — a shift change, a match kick-off, a billing run at midnight. A system built for average load and hit with a burst fails exactly when it matters most.
The estimate we actually write
- Peak concurrency — the worst plausible number of simultaneous users in the busiest five minutes, not the busiest day.
- Write ratio — what fraction of that traffic changes data versus reads it. Reads are cheap to scale; writes to a single row are not.
- Failure tolerance — what the product is allowed to do when it is over capacity: queue, degrade, or reject. Deciding this in the design phase is far cheaper than discovering it live.
Model the bottleneck, don't guess at the whole system
Most systems have one component that falls over first — a database table with a hot row, a third-party API with a rate limit, a queue consumer with a fixed pool size. We identify that component early and estimate its ceiling specifically, because a generic load test of "the app" tends to prove that the parts which were never going to be the problem indeed are not the problem.
The expensive mistake is not under-provisioning. It is over-provisioning against the wrong bottleneck and still falling over at the real one.
A recent example
A booking feature we scoped this year had a write ratio nobody expected: every view of a slot also wrote a soft lock, to stop two people booking it at once. The read-heavy assumption from the brief was wrong, and it changed the data model before any code existed — locks got a short expiry and a separate table, rather than living on the slot row itself.
What this buys the client
A design that survives its first real traffic spike without a rewrite, and a much shorter list of things to load test once the feature exists, because the risky part was already isolated on paper.