When to split a monolith (and when not to)

Splitting a monolith is an architectural trade-off, not a maturity badge. A monolith can be simple, fast to change, and reliable when it has clear internal boundaries. Microservices can improve autonomy and scaling, but they also add network calls, distributed data, deployment coordination, observability requirements, and operational cost.

Start with the problem

Do not split because the codebase is large. Split because there is a specific pressure that a single deployable unit cannot handle well.

Good reasons include independent delivery needs, different scaling profiles, clear ownership boundaries, conflicting reliability requirements, or a domain area that changes at a different pace from the rest of the system. Weak reasons include fashion, resume driven design, or the hope that network boundaries will fix poor modularity.

Keep the monolith when it is working

A monolith is often the right choice when the team is small, the domain is still changing quickly, and service boundaries are not yet clear. In that stage, a distributed design can freeze bad boundaries early and make refactoring harder.

A modular monolith can give many of the benefits of separation without the operational cost of distributed services. Use explicit modules, clear ownership, internal APIs, dependency rules, and separate tests. Enforce boundaries in code review and tooling. If the team cannot keep boundaries inside one process, it will usually struggle to keep them across a network.

Signals that a split may help

A split may be justified when one part of the system needs to deploy frequently while the rest must remain stable. It may help when one capability needs very different resource scaling, for example CPU heavy processing separate from normal request handling. It may help when a component has a distinct data model, a stable interface, and a team ready to own it from code to operations.

A split can also reduce blast radius. If a non-critical capability fails often and currently affects critical paths, extracting it behind a resilient interface can make the overall system safer. This only works when the new service boundary reduces coupling rather than moving it into synchronous calls and shared databases.

Signals that a split is premature

A split is premature when the team cannot describe the boundary in business terms. It is also premature when the proposed service needs direct access to many tables owned by the monolith, shares domain objects freely, or requires coordinated deployments for routine changes.

Other warning signs include no automated deployment, weak observability, no centralised logging, no tracing across calls, no clear service ownership, and no tested rollback process. Microservices need these capabilities early. Without them, incidents become harder to understand and slower to recover.

Data is the hard part

Code is usually easier to split than data. A service boundary is weak if the new service and the monolith keep writing the same tables. Shared databases preserve coupling while adding network and deployment complexity.

Prefer boundaries where a service can own its data and expose behaviour through an API or event stream. When that is not possible, plan the migration explicitly. Transitional patterns can include read replicas, change data capture, synchronisation events, dual writes with reconciliation, or an anti-corruption layer. Each choice has failure modes.

Use incremental migration

A big rewrite is rarely the safest path. The strangler fig pattern replaces selected behaviour gradually while the old and new systems coexist. Routing, facades, events, or API gateways can direct part of the traffic to the new implementation while the monolith continues to serve the rest.

Start with a capability that has clear boundaries and measurable value. Avoid extracting the most central and tangled component first. A successful first extraction should prove deployment, monitoring, rollback, data ownership, and on-call readiness.

Define the service contract

Before extraction, define the contract. Include inputs, outputs, error behaviour, timeouts, retry guidance, idempotency, authentication, authorisation, versioning, and ownership. A service is not independent if every change requires lockstep changes in its consumers.

Keep contracts small and business focused. Do not expose the new service as a remote version of its internal tables. That creates a distributed monolith.

Operational readiness

Each new service needs build pipelines, deployment automation, metrics, logs, traces, alerts, dashboards, runbooks, capacity limits, dependency maps, and security controls. It also needs an owner who can respond when it fails.

This cost is acceptable when the service provides enough autonomy, resilience, or scaling benefit. It is waste when the split only adds another place for the same team to deploy the same change.

Decision checklist

Split when most of the following are true.

Boundary

The capability has a clear business boundary, stable language, and limited coupling to the rest of the system.

Ownership

A team can own the service, its data, its reliability, and its deployments.

Benefit

The split improves delivery speed, scaling, resilience, compliance, or cost in a measurable way.

Readiness

The platform supports automated deployment, observability, rollback, secrets, and access control.

Migration

There is an incremental path that avoids a high risk rewrite.

Do not split when the main problem is messy code, unclear domain modelling, weak tests, or poor deployment discipline. Fix those first.

Conclusion

Split a monolith when a clear boundary and measurable benefit justify the extra distributed systems cost. Keep it together when the domain is still fluid, the team is small, or the platform is not ready. A well-structured monolith is not a failure. A poorly separated set of services is still a monolith, only slower and harder to operate.