Microservices vs monolith is the architecture debate that refuses to die because the right answer genuinely depends on team size, domain complexity, and operational maturity. The “microservices everywhere” gospel of 2015 has rightfully cooled into a more nuanced view: monoliths scale further than people thought, and microservices cost more than people admitted. The teams making good decisions in 2026 ask sharper questions. Here is the decision framework that actually works.
Table of Contents
Start With a Modular Monolith
For teams under 30 engineers, a well-structured monolith almost always wins. You get atomic database transactions, refactoring support that crosses module boundaries, and a single deploy unit that any developer can run locally. The cost is discipline — module boundaries have to be enforced.
Tools like Spring Modulith, the dotnet ArchUnit equivalent, or simple linting rules help. The Martin Fowler “MonolithFirst” essay remains the canonical argument and is more relevant than ever. Microservices are a refactoring you do later if and when you need them.
Conway’s Law Drives Service Boundaries
If you do split, the boundaries should follow team boundaries, not technical neatness. A service owned by no team is a service nobody maintains. A service owned by two teams creates coordination overhead that defeats the purpose.
The two-pizza-team rule from Amazon is the practical heuristic: each service should be ownable by a team of 6-10 engineers including PM, design, and on-call coverage. Below that, you do not have the people. Above that, you have a coordination problem.
Operational Complexity Is the Hidden Cost
Microservices multiply your operational surface area. Distributed tracing, service discovery, secrets management at scale, mTLS between services, circuit breakers, retries, dead letter queues. Each one is solvable; together they are a platform team.
If you do not have or want a platform team, do not adopt microservices. The monolith is dramatically cheaper to operate at small scale. See our Kubernetes basics guide for the infrastructure layer that microservices typically require.
Data Ownership Beats Service Boundaries
The cleanest microservice boundaries are around data ownership. One service owns the orders table; nobody else writes to it directly. The service exposes APIs for everyone else. This avoids the worst microservice anti-pattern — the shared database — which gives you all the costs of microservices and none of the benefits.
Database-per-service is the rule. If two services need to share data, one of them does not actually exist as a separate service yet. The Database per Service pattern documentation covers the trade-offs.
Event-Driven Reduces Coupling
Synchronous service-to-service calls multiply your latency and create distributed monoliths. Async messaging through Kafka, NATS, or even SQS lets services evolve independently and degrade gracefully when downstream services have issues.
The trade-off is eventual consistency, which forces business logic to handle async outcomes explicitly. For most domains this is fine; for some (financial transactions, inventory reservations) you need patterns like the saga or outbox to maintain correctness.
Wrap Up
Microservices vs monolith is a decision to make consciously, not by default. Start with a modular monolith, split only when team or scale forces it, follow Conway’s Law for boundaries, and own your data per service. Most teams over-microservice and pay for it in operational complexity. Pair this thinking with serverless architecture pros and cons for the full distributed systems picture.
Frequently Asked Questions
When should I split a monolith?
When deployment coordination becomes the bottleneck (multiple teams blocked on a single release train), when scaling requirements diverge wildly (one part needs 100x the resources of another), or when team boundaries are clearly forming around domain areas.
Are microservices necessary for scaling?
No. Stack Overflow ran their monolith on a handful of servers serving billions of requests. Shopify scaled to massive volume on a Rails monolith. Microservices are a team-coordination tool, not a scaling tool.
What’s a “modular monolith”?
A monolith with strict internal module boundaries — code in module A can only depend on module B’s public API, not internals. Tooling enforces it. You get most of the architectural benefits without the operational cost.
Should every service have its own database?
Yes if it is truly a separate service. Shared databases create the worst kind of coupling. If two services genuinely need to share a database, you have one service in two deploy units.
What about microfrontends?
Same advice as microservices, scaled to the frontend. Adopt only when team coordination at the build/deploy layer is genuinely the bottleneck. Most teams do not need them.
