The pendulum swings. After a decade of the industry charging toward microservices, a counter-movement is gaining momentum: the modular monolith. Neither architecture is universally superior — the right choice depends on team topology, scale, and deployment maturity.
The Case for Microservices
Microservices excel when:
- Teams are large enough to own independent services (Conway's Law applies).
- Services have genuinely different scaling requirements (e.g., video processing vs. authentication).
- Technology heterogeneity is a deliberate choice (Python for ML, Go for the API gateway).
- Independent deployability is a hard business requirement.
The Case for the Modular Monolith
For the vast majority of startups and mid-size organisations, microservices introduce distributed systems complexity before the team has the operational maturity to manage it. A well-structured monolith with clear module boundaries offers:
- Simpler local development (no service mesh, no port juggling).
- Easier refactoring (rename a function across the entire codebase with confidence).
- Faster initial velocity without the operational overhead of Kubernetes, service discovery, and distributed tracing.
The Emerging Middle Ground
Tools like Encore, Nx, and Turborepo are compressing the gap. They allow teams to build with module-level separation and deploy as either a monolith or mapped microservices depending on load. This "deploy-shape agnostic" development is fast becoming the pragmatic default.
How to Decide
Ask three questions: How many independent teams do you have? Are your scaling profiles genuinely divergent? Do you have an SRE function or equivalent operational capability? If the answer to most is "no," start with the monolith and extract services only when you feel the pain of not having them.
KEY INSIGHT "Premature microservices decomposition is the most expensive architectural anti-pattern in the industry right now."