Harden the operation before the volume arrives
Scaling is rarely a performance problem first. It is usually an operations problem that performance makes visible.
- Method
- Operations
- Engineering
The last stage of my method is Scale, and its instruction is to harden the operation before the volume arrives, not after. Most teams do it the other way round: they wait for load, discover what breaks, and fix it under pressure.
That works until it doesn't, and when it doesn't, it fails in front of the customers you worked hardest to win.
Scale is mostly operations
When people talk about scaling, they usually mean performance: faster queries, more servers, better caching. Those matter. But in my experience, the first things to break under growth are rarely the database. They are the processes around it.
- Manual steps. Something a person does by hand for every new customer, order or listing. Fine at ten a week. Impossible at a thousand.
- Support load. Every confusing screen and ambiguous error generates tickets. Volume multiplies them.
- Moderation and review. Human review that keeps up at launch falls behind silently as volume grows, and quality quietly degrades.
- Silent failures. A background job that occasionally fails and nobody notices becomes a steady stream of lost work.
- Knowledge in one head. An operation that depends on one person knowing how things work stops when that person is busy, ill or gone.
What hardening looks like
Automate the repeated. Any manual step that happens per-unit — per order, per user, per upload — is a scaling liability. Automate it, or at least make it a one-click action with the context already assembled.
Make failure visible. Every background process should report success and failure somewhere a person will see it. A job that fails quietly is worse than one that fails loudly, because loud failures get fixed.
Fail safely. When something does break, the system should degrade in a way that protects users: keep the data, queue the work, tell the user what happened. Losing a message is worse than delivering it late.
Write down how things work. Short runbooks for the operations that matter: how to restore, how to reprocess, how to rotate a credential. Written before the incident, not during it.
Rate-limit the edges. Anything the public can trigger — forms, uploads, sign-ups — needs limits before someone discovers it has none.
Performance still matters
Hardening the operation does not replace performance work. It makes performance work possible, because a team that is not firefighting manual processes and silent failures has the attention to profile and optimise properly.
The takeaway
Before a launch, a campaign or a big customer, walk through one unit of work end to end and list every step a person touches. Then list every step that could fail without anyone knowing. Fix those two lists first. That is most of what "ready to scale" really means.