A commerce platform runs a very large monolith serving enormous traffic and chooses not to decompose it into microservices. What must be true for that to be the right choice?

What must be true

1. Internal boundaries are enforced mechanically, not by convention. Module structure with static checks on dependency direction, so a component cannot reach into another's internals. Without this a large monolith becomes a big ball of mud, and the argument for keeping it collapses.

2. Ownership is explicit per module, so unowned code is a build failure rather than a wiki gap.

3. The deployment pipeline is fast and safe enough for the change volume — because everything ships together, so a slow or unreliable pipeline blocks everyone at once.

4. The scaling constraint is not one subsystem needing radically different resources. If one part needs ten times the CPU of the rest, extract that part. Decomposing everything because one component has a scaling problem buys a large amount of distributed-systems cost for a benefit one extraction delivers.

5. Blast radius is managed another way — cells, sharding by merchant, or traffic isolation — since a monolith without isolation means one failure affects everyone.

What it buys

• No distributed-systems tax: no network partitions between components, no eventual consistency where a transaction would do, no distributed tracing required to answer basic questions.
• Refactoring across boundaries is a code change, not a migration. Moving a responsibility between modules is an afternoon; moving it between services is a project.
• One deployment, one runtime, one place to debug.
• Transactions still work, which removes an entire class of saga and compensation complexity.

What it costs

• Coupled deployment. Everything ships together, so one team's problem can block another's release.
• Coupled scaling, so the whole application scales to the needs of its heaviest component.
• A single failure domain unless cells are added.
• Technology uniformity, so a workload genuinely suited to a different runtime has no home.

The judgement

Microservices solve an organisational scaling problem and cost a distributed-systems problem. If the organisation can coordinate — through enforced module boundaries, good tooling and clear ownership — the monolith avoids costs that are permanent.

The signal to decompose is not size. It is teams blocking each other, or one component needing a materially different operational profile — and the correct response to the second is to extract that component, not to decompose everything.