Monolith versus microservices is the wrong first question
Start from team shape, data ownership, and release pain. The topology should follow those facts.
The industry talks about monoliths and microservices as moral categories. They are deployment and ownership strategies. A well-modularized monolith can be a precise, cheap system. A distributed estate can also be a slower monolith with network latency.
Ask what is actually hurting
If the pain is test time, unclear module boundaries, or a shared database that every feature touches, splitting into processes will not help until those are addressed. If the pain is independent scale, independent release across teams, or a domain that really does fail independently, distribution can pay for itself.
A modular monolith is a real destination
Put modules behind interfaces. Stop sharing tables across those interfaces. Add contract tests. Many organisations should stop there. You get clarity without paying for distributed tracing, eventual consistency, and a pager for every repository.
If you extract, extract a seam
- Choose a capability with a second consumer or a distinct risk profile.
- Give it data ownership. A service that reads and writes the old tables is a function call with extra failure modes.
- Keep a compatibility layer so the rest of the system does not have to change in the same release.
- Do not dual-write “for a while” without a reconciliation and an end date.
If the same three people own every service, you have multiplied the moving parts without multiplying the ownership.
Common questions
Should I use a monolith or microservices?
Start from what is hurting. Independent scaling, independent release across several teams, or domains that fail independently can justify microservices. Slow tests, unclear boundaries, or a shared database usually call for a modular monolith first, which is cheaper to run and keeps extraction possible later.
When should you not use microservices?
When one small team owns the whole system, when release cadence is already healthy, when there is no automated deployment and tracing, or when services would still share a database. In those cases distribution adds latency, failure modes, and operational load without delivering independence.
This article supports our microservices architecture services. If the situation it describes is familiar, tell us about the systems involved.
