Modular monolith vs microservices in 2026: scale the architecture when the team needs it

[Aior]

The architecture pendulum has swung​

The microservices-by-default era is over. The modular-monolith pattern has reasserted itself, and most teams in 2026 are happier with a well-structured monolith than they would be with five microservices doing the same job. The question isn't "monolith or microservices" — it's "when does the cost of distribution start paying off, and how do I avoid the worst of both".

The modular monolith — the right default​

A modular monolith is a single deployable that's organised internally as separate modules with explicit interfaces. The pattern:

• Modules expose narrow APIs (functions or events) to each other; no direct database access across module boundaries
• Each module owns its tables; if a foreign module needs the data, it goes through the API
• The build enforces module boundaries — Maven multi-module, dotnet projects, package boundaries in Go, etc.
• One deployable, one process, one database (or one logical database per module within shared infra)

What you get: low operational overhead, fast in-process calls, single transaction boundaries, simple deployment. Most of the maintainability benefits of microservices without the cost.

When it stops being enough​

Move a module out to its own service when:

• The module has materially different scaling characteristics from the rest (e.g. video transcoding inside a CRUD app)
• The module has materially different reliability requirements (e.g. payment processing needing higher availability than the surrounding admin tooling)
• The team boundary has shifted — a separate team is going to own this and they need autonomy on deploy cadence
• The technology mismatch is real — one module is genuinely better in a different language / runtime

Don't extract for "microservices best practice". Extract for a specific reason that survives a sceptical review.

The "service boundary" question[/HEADING>
A service boundary is a deployment boundary, a team boundary, and a data ownership boundary all at once. Get any of these wrong and the service is worse than the module it replaced.

The DDD-style heuristic: bounded contexts. A service should own a coherent domain — orders + order items + order lifecycle, not "the orders table". Sharing tables across services is a smell that becomes a maintenance disaster.

The middle ground that usually fails: distributed monolith​

A distributed monolith is what you get when you split a monolith into services but keep the synchronous call patterns and shared databases. You pay the operational cost of distribution and get the maintenance cost of coupling. Worst of both.

Signs you have one:

• A change to one service requires a coordinated deploy of three others
• Service A reads from service B's database directly
• An incident in one service cascades to all of them within a minute
• Local development requires running 8 services

If you're here, going back to a modular monolith is the cheaper option than fixing the distribution.

Patterns that survive at scale​

• Async messaging (Kafka, NATS, RabbitMQ) for cross-service workflow — synchronous chains amplify failures
• Saga pattern for cross-service transactions — XA / 2PC is rarely the right answer
• API gateway / BFF pattern for external clients — don't let external consumers know the internal service topology
• Schema registry — when services exchange messages, schema evolution is its own engineering investment

One pattern we'd warn about​

Designing the v1 architecture for the v3 scale. The team that ships microservices on day 1 to "be ready for scale" is usually still struggling to get traction at month 18. Build for the team and the load you have. Re-architect when reality demands it. Architecture changes are normal.

What's your current architecture? And — for the migration folks — how do you decide when to break a module out vs leave it in the monolith?​