System Modernization and Scaling

A change that used to take two days takes two weeks, because the effect of touching one part is no longer predictable. Deployments have become events, scheduled for evenings, attended by several people. Two developers who understand a critical component are the only ones who will go near it. The infrastructure bill grew faster than usage and nobody can point at the cause. None of these is an outage. Together they mean the business now moves at the speed of its oldest system.

Teams tend to nominate the component they find most unpleasant to work with, which correlates poorly with the component that is actually limiting you. A module everyone dislikes can be perfectly adequate at current load, while the real ceiling sits in a database connection pool or a nightly job whose runtime has been quietly growing with the data.

So the first step is a load test that pushes the system until something gives, plus query analysis and tracing under real traffic. The result is a specific constraint and a specific number. That changes the conversation from "the system is old" to "we handle roughly this much concurrency and the limit is here", which is something you can plan and budget against.

Billing, notifications, reporting, document generation, file processing: these tend to have naturally narrow interfaces because they were always somewhat separate in how the business thinks about them. Pulling one out is a contained piece of work with a testable result. Cutting across a boundary that does not exist (separating "the frontend part" of a domain from "the backend part") produces two components that have to talk constantly, and you have replaced function calls with network calls that can fail.

The first extraction should be chosen for low risk rather than high importance. Its job is to prove the approach, establish the patterns and give the team confidence, on something that will not take the business down if it goes badly.

One database handling both reads and writes when the read load dominates. One background worker processing a queue that occasionally spikes. One server holding uploaded files on local disk, which is also the reason it cannot be duplicated. One synchronous call to a third-party API inside a request that users are waiting on.

Each of those has a well-understood fix, and none of them requires a rewrite. What they require is knowing which one binds first, which is why the measurement comes before the plan.

This is unglamorous and it is what separates modernisation that finishes from modernisation that gets cancelled. Long-running programmes with no releasable state in the middle accumulate risk quietly and become impossible to stop or redirect. When the business context changes (and over a long programme it will), you want to be at a point where stopping is an option rather than a disaster.

It also means the benefit arrives progressively. Deployment gets easier before the whole thing is done. Response times improve after the first performance pass rather than at the end. That matters, because sustained support for this kind of work depends on people seeing it produce something before the final step.