Every project runs into the same awkward question, usually about ten minutes into the first call. How big should we build this? Ask three developers and you will get three confident answers, none of them written down, each one shaped by whatever the last project happened to need.
We would rather do arithmetic. Not difficult arithmetic. The kind you can do on the back of an envelope while the kettle boils, using numbers that come from your business rather than from somebody's instinct about what a modern system ought to look like.
The questions come before the technology
Before anyone draws a box or argues about a database, we ask a short list of questions. None of them are technical. You already know most of the answers, and the ones you do not know usually turn out to be worth finding out anyway.
How many people, and when do they turn up
Monthly visitors is a number for investors. It tells us very little. Thirty thousand a month spread evenly is one person every ninety seconds, which almost anything can handle. Thirty thousand a month where eight thousand arrive the morning tickets go on sale is a completely different piece of software. The busiest hour is the system you are actually paying for. The rest of the month is quiet by comparison.
What are they doing while they are there
Reading is cheap. Writing is expensive. Somebody browsing twenty pages costs less than somebody finishing one checkout, because the checkout has to check stock, take money, write a record and send a confirmation, and it has to manage all of that without ever ending up half done. So we count actions, not visitors.
How much data is there, and how fast does it grow
A search across five hundred records is instant however badly it is written. The same search across five million is a different experience entirely. Most of the slow systems we get asked to look at were not slow when they launched. They simply filled up, quietly, over about two years.
How quickly does it need to feel
Fast is not a plan. A number is. Under a second for a page, a couple of seconds for a search, ten seconds for a report nobody sits and watches. Once those are written down they can be tested, and everybody stops arguing from taste.
What must never fail, and what can wait
Not every part deserves the same protection. If the payment path stays up while a dashboard graph goes missing for an hour, most businesses get through the afternoon comfortably. Reverse it and nobody is comfortable. Knowing which is which changes where the effort goes, and usually saves money.
What does it lean on that you do not control
Payment providers, SMS gateways, calendars, delivery partners. Each has its own limits, and the moment you depend on one, their ceiling becomes your ceiling. Far better to know that number in advance than to learn it during your best hour of trading.
What is it allowed to cost to run
Monthly hosting is a design input, not a surprise on a card statement. Tell us the budget early and the design bends around it. Mention it after launch and something has to be unpicked.
Then we do the sums
Here is the entire method, on a launch that expects ten thousand visits in its first day.
Two requests a second. That is the honest answer, and it tends to disappoint people who were braced for something more dramatic. Two a second is not much at all. But traffic clumps rather than spacing itself out politely, so we design for several times that, somewhere between eight and twenty a second in this example. We would rather carry headroom we never use than go looking for it at ten past nine on launch morning.
The arithmetic is not the clever part. The clever part is that it exists on paper, where you can disagree with it. If you think ten thousand is optimistic, or that the rush lasts thirty minutes rather than two hours, say so and the numbers move. Nobody has to take anybody's word for anything.
What the three layers are actually doing
Nearly everything we build has three parts, and it helps to know who talks to whom, because that is what explains where things pile up when it gets busy.
The screen never speaks to the database directly. It asks the backend, the backend decides whether that request is allowed and who is making it, and only then does the database get involved. It looks like a detour. It is the reason your data does not walk out of the building the first time somebody curious starts poking at the page.
It is also where capacity lives. The frontend usually copes with far more people than the rest of the chain. The middle hop is where a queue forms first, which is why we size the backend and the database together and never one without the other.
Headroom is a decision, not a feeling
We aim for something that can absorb roughly five to ten times the expected peak without needing to be redesigned. That range covers nearly every launch that goes well. Past that point you are buying insurance against a scenario nobody can describe, and paying for it every month until you stop.
The goal is not a system that cannot break. It is knowing what breaks first, and how long it takes to add room.
Capacity gets added in stages
You do not need all of this on day one, and buying it early is how budgets quietly disappear. Each stage has a signal that says it is time. Until the signal shows up, the stage is a cost with nothing to show for it.
Plenty of products sit happily on the first two steps for years. We have also seen teams jump straight to the last one before they had a single customer, because that is what big companies do, and then spend their budget maintaining a shape nobody needed yet. Taken in order, in response to something that has actually happened, these steps are cheap.
The part where we try to break it
Before launch, a copy of the system gets a rehearsal. Thousands of pretend customers do what real ones are about to do, all at once, while nobody is watching. It gives us the measured number rather than the calculated one, and the two are never quite the same. Finding the limit on a quiet Tuesday costs nothing. Finding it on launch day costs customers.
What you end up holding
- A number: how many people at once, comfortably, with the working shown.
- The name of the first thing that will give way, and a rough idea of when.
- Which stage you are on, and what the next one would cost.
- Alerts set below the limit, so a warning arrives before a problem does.
- A plan for the day demand goes past all of it, because occasionally it will.
None of that makes a product exciting. It makes a launch boring, which is the correct ambition for a launch.
If you already have something running and nobody has ever done this arithmetic for it, you are in the majority. Working out where you currently stand is usually a short piece of work, and it is a fair amount of what we get asked for.