Split the system, or keep it whole

Not if it has internal boundaries. A modular monolith keeps clear module edges, with separate domains and no module reaching into another module's tables, while still deploying as one unit. When a module genuinely needs to leave, the seam is already drawn and the extraction is contained work rather than a rewrite. The debt comes from a monolith with no boundaries at all, where every part reads every table. That is a discipline problem, and splitting into services does not fix it. It moves it onto the network, where it is harder to see.

The trigger is organisational before it is technical. Watch the release meeting: when shipping means coordinating three teams' changes into one deploy window, and one team's feature is regularly held back by another team's bug, the shared deployable has become the bottleneck. The second trigger is a workload with a genuinely different shape, like video transcoding or model inference that wants different hardware. Slow response times on their own are not a trigger. That is usually a missing index or an N+1 query, and splitting the code will make it worse.

They are describing scaling teams, not scaling traffic, and the pitch tends to blur the two. A single well-built application on a decent database handles far more load than most products ever see, and you scale it by running more copies behind a load balancer. What services buy you is scaling one part independently, which matters when one workload is genuinely expensive. Ask which specific component they expect to outgrow the rest, and at what traffic. If there is no answer, the recommendation is a default rather than a diagnosis.

Mostly time in places that produce nothing a customer can see. You need service-to-service auth, a broker or an API gateway, tracing so a single error is followable across hops, a pipeline per service, and a plan for the window where one service reads the new schema and another still reads the old one. Expect that groundwork to add weeks before the first feature lands, then to keep taking a share of every sprint. It earns its keep when it removes a real coordination cost, and it is dead weight when it does not.

Yes, and it is the path we recommend most often. We build the first version as a modular monolith with the domain boundaries drawn deliberately, so orders, billing and identity do not share tables even though they share a process. When one of them needs to move out, it leaves behind an interface that already exists. Going the other way, folding a service estate back into one deployable, is also something we do, but it is harder because you inherit whatever data drift built up while the databases were separate.