Microservices vs. Monoliths: The Pendulum Swings Back
After a decade of breaking everything into microservices, many teams are discovering that a well-structured monolith might have been the answer all along.
Elena Marchetti
Lisbon, Portugal
The microservices revolution promised scalability, team autonomy, and technological flexibility. And for companies operating at massive scale, it delivered. But for the majority of engineering teams, it introduced complexity that far outweighed its benefits.
The Hidden Costs of Microservices
What the microservices evangelists didn't always mention was the operational overhead: distributed tracing, service mesh management, data consistency challenges, and the cognitive load of understanding a distributed system.
A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable. — Leslie Lamport
For a team of 5-20 engineers, managing a dozen microservices often means spending more time on infrastructure than on product features.
The Modular Monolith
The emerging wisdom is the modular monolith: a single deployable unit with well-defined internal boundaries. You get the organizational benefits of service thinking without the operational complexity of distribution.
- Clear module boundaries: Each domain has its own directory structure and interfaces.
- Single deployment: One artifact to build, test, and deploy.
- Shared infrastructure: One database, one cache, one monitoring stack.
- Easy extraction: When a module genuinely needs to be a service, the boundaries are already defined.
The best architecture is the one your team can effectively operate. For most organizations, that's a well-structured monolith — and there's no shame in that.
