A platform must choose between a modular monolith and microservices for a new product line. What evidence should decide it?

The evidence

1. Number of teams that will change this code. Microservices solve an organisational scaling problem: many teams shipping independently. With one or two teams, that problem does not exist and the distributed-systems cost is paid for nothing.

2. Whether one component needs a materially different operational profile. Much higher volume, longer-running work, stricter latency, a different availability requirement. This justifies extracting that component — not decomposing everything.

3. Whether the domain boundaries are actually known. For a new product line they usually are not. Choosing service boundaries before the domain is understood means guessing, and a wrong service boundary is far more expensive to correct than a wrong module boundary.

4. Whether the organisation can operate a distributed system — tracing, correlation identifiers, retry budgets, deadline propagation, per-service capacity. If these do not exist, the first incident will be undiagnosable.

The default for a new product line

A modular monolith with enforced boundaries. Static dependency checks, explicit module ownership, no shared tables between modules, and module-level tests.

This delivers most of the change-cost benefit of decomposition without the distributed cost, and — decisively — it produces the evidence needed later: modules that have changed independently for a long period are proven extraction candidates, and modules that keep changing together are proof that the proposed boundary was wrong.

When to extract

On a specific trigger, not on a schedule: teams blocking each other on releases, or a component whose operational profile genuinely diverges. Extract that boundary, keep the rest.

The reframing worth stating

Reducing distribution is a legitimate architectural improvement when the constraint is change velocity rather than runtime scale. A platform with three teams and forty services has paid the distributed-systems charge and not received the organisational benefit — and framing consolidation as a retreat is what prevents teams from making an obviously correct correction.