What It Actually Means
The word has acquired a negative tone it does not deserve. It is used to mean outdated, and it describes an architecture that is correct for the overwhelming majority of business systems, including some very large ones.
Why It Is Usually Right
Everything is in one place. Following what happens when an order is placed means reading one codebase rather than tracing a request across five services and a message queue.
Changes are simple. A feature touching three areas is one change, tested together and deployed once. In a distributed system it is three coordinated changes across three deployments.
Data stays consistent. One database, ordinary transactions, and an operation either completes or does not. Keeping data consistent across separate services is genuinely difficult and is where distributed systems produce their most confusing failures.
It is cheaper to run and to staff. One thing to deploy, monitor, secure and understand. A small team can hold it in their heads.
For a business system serving a company rather than the public internet at scale, none of the reasons to split apply, and all the costs of splitting do.
When The Word Is Being Used Against You
Listen for it in the argument for a rewrite, because it does a specific job there: it makes the existing system sound obsolete without anyone having to demonstrate a problem.
The useful response is to ask what is actually going wrong, and to check the answer describes something a different architecture would fix. Slow development, frequent bugs and difficulty making changes are usually technical debt or unfamiliarity, and splitting a poorly structured application into services produces several poorly structured services that now also have to talk to each other over a network.
Distribution does not fix structure. It relocates the problem and adds latency, failure modes and operational overhead.
When Splitting Genuinely Helps
Real cases exist and they are recognisable.
One part has completely different scaling needs, such as heavy processing that would otherwise require scaling everything. One part has a different reliability requirement and must not be affected by the rest. Separate teams need to release independently and are genuinely blocked by each other. Or one component needs a different technology for a good reason.
Note that most of those are organisational rather than technical, and most only appear at a size where you would already have several teams.
What To Ask
- What specific problem does splitting solve? It should be something measurable.
- What does it cost to run afterwards? Deployment, monitoring, tracing across services, and the debugging that becomes considerably harder.
- Who operates it? Distributed systems need operational maturity. Without it you have the complexity and none of the benefit.
- Could we get the same benefit by improving the structure inside the current application? Very often yes, at a fraction of the cost.
The Sensible Default
Start as a monolith, keep it well structured internally with clear boundaries between areas, and extract a service only when a specific pressure justifies it.
That path keeps the option open without paying for it in advance, and it is the sequence most experienced teams now recommend after a decade of the industry discovering the cost of the alternative. A well-organised monolith is not a compromise; for most businesses it is the answer.
More terms are in the glossary.
