Microservices vs Monolith: Making the Right Architectural Call
The microservices-vs-monolith debate is not about technology — it is about organisational structure, scale, and the true cost of distributed systems.
The Pendulum Has Swung Back
For most of the 2010s, microservices were the architectural aspiration of every engineering team. By the early 2020s, a correction began. Amazon, Netflix, and Shopify — the companies most cited as microservices success stories — started publishing honest post-mortems about the operational complexity, latency overhead, and data consistency challenges of large distributed systems.
Stack Overflow migrated parts of its infrastructure back to a monolith. Segment rebuilt a microservices system as a monolith to reduce complexity. The honest message: microservices solve real problems, but they introduce new ones. The question is not which architecture is better in the abstract — it is which trade-offs are worth making at your current scale.
What a Monolith Does Well
A well-structured monolith (sometimes called a 'modular monolith') is simple to develop, test, debug, and deploy. There is one codebase, one deployment unit, one database transaction boundary. Cross-module communication is a function call, not a network request — which means no serialisation overhead, no network latency, and no partial failure scenarios.
For teams under 30 engineers building products under five years old, a monolith is almost always the right starting architecture. The speed advantage of a monolith in the early stages of a product is significant, and the eventual migration to services (if needed) is much easier from a well-structured modular codebase than from a messy one.
When Microservices Are Worth the Complexity
Microservices make architectural sense in a specific set of circumstances: your engineering organisation is large enough that independent deployability materially speeds up delivery (generally 50+ engineers), different parts of your system have genuinely different scaling characteristics and co-locating them is wasteful, you need independent technology choices per service (e.g., ML inference service in Python, CRUD API in Go), or regulatory requirements demand strict data isolation between domains.
The key word is 'genuine'. Many microservices migrations are driven by architectural fashion rather than operational necessity. If your system is a single-region web application with uniform traffic patterns and a 20-person engineering team, you are probably creating distributed systems complexity without capturing distributed systems benefits.
The Middle Ground: Modular Monolith
The modular monolith is underappreciated as an architectural pattern. It enforces module boundaries (each module has a public API and cannot directly access another module's database tables or internals) but deploys as a single unit. You get the development simplicity of a monolith with the boundary discipline that makes eventual service extraction tractable.
In practice: domain-driven design with clearly bounded contexts, enforced module isolation through code linting rules or package access controls, and a shared database with separate schemas per domain. When — and if — a module needs to become a service, the interfaces are already defined and the dependencies are explicit.
Migration Patterns for When You Need to Split
If you have a genuine bottleneck in your monolith that requires service extraction — a resource-intensive background processing pipeline, a high-traffic read path that needs independent scaling, a team ownership conflict over a domain boundary — the strangler fig pattern is the safest migration approach.
Extract one service at a time, starting with the domain with the cleanest boundaries and least cross-cutting state. Keep the data in the same database initially (or use database views for isolation) before tackling polyglot persistence. Introduce a message broker only when you have clear asynchronous communication patterns, not speculatively. Each extraction should be independently deployable and reversible.
Work With Us
Ready to put this into practice?
iSpecia builds what you've been reading about. Tell us your challenge.