Follows a review · Bottlenecks, regions, headroom
Scaling Systems
The money is committed and the date is in a board deck. The one line item nobody costed is the platform underneath the plan. Scaling is removing the part that gives first, building what a second market genuinely requires, and proving the headroom against the number in the plan rather than hoping for it.
Scoped by the two-day Architecture Review. A scaling programme quoted before anyone measured is just a bigger guess.
Which platforms this is for
A platform already carrying real traffic, a load target that comes from a plan rather than a guess, and a date somebody outside engineering is holding you to. Measurement only means something when there is traffic to read and a number to read it against.
It fits badly before launch, when there is no load to measure and the honest answer is to ship and find out. And if what is actually hurting is versions and dependencies rather than the load you are heading for, Systems Modernisation is the branch to read instead.
What gets changed, and what deliberately does not
Scoped from what the review measured, and ordered by what blocks the date.
01
The part that gives first, removed
A connection pool, a synchronous call sitting in the signup path, a table that was entirely reasonable at a million rows. The review names it. This is the work of fixing it and measuring again to prove it actually moved.
02
What a second market requires, built
Data residency, payment rails, regulatory reporting, a deployment that has to exist in region. None of it is the current system with a flag set, and all of it deserves designing as the new work it is.
03
Headroom proved, and what it costs
Load tested at the figure the plan assumes rather than the traffic you have today. Headroom is a number or it is a feeling. The infrastructure bill at that number is the other half of the answer, and it occasionally changes the commercial plan rather than the technical one.
04
Everything else deliberately left alone
Usually most of it. The parts the review found sound stay untouched, with the measurements attached — which is what stops a full platform rebuild being funded by default in the month after a raise.
Less rewriting is not less building. The parts that are genuinely new get designed properly here, and they can be, because the budget was not already spent replacing things that were working.
Launch day and the day the traffic actually arrives are not the same date. Work that only has to hold for the second one comes off the critical path for the first, and separating them is usually what creates the room to act.
The regional-or-central decision nobody has made yet
Underneath the new-market work sits one decision: which data and which services genuinely have to live in the region, and which can stay central.
It is cheap to make on paper and structural once traffic is on it — reversing it later means moving live data across a border while a launch date is running. It is usually made in a hurry by whoever is closest to the deadline, and this is the work that makes it deliberately instead.
What you have at launch
A platform measured at the load the plan assumes rather than hoped at, the regional pieces built and running, and a load test your own team can run again — before the next market, or the next raise. The parts left alone stay left alone, with the evidence for why.
The second market is a smaller job than the first, because the seam between what is regional and what stays central already exists and somebody has already argued about where it sits.
The date does not move
The review is two days and a fixed fee. A bottleneck found early is a piece of work. The same bottleneck found late is a launch date being renegotiated in front of the people who funded it.