Microservices vs. Monolith: Choosing the Right Architecture for Growing Teams
Microservices sound modern and monoliths sound outdated, but the trade-offs are real. This guide helps growing teams choose architecture based on context, not trends.
“We need microservices.” I hear this often - sometimes in the very first meeting, before anyone has really thought through the requirements. Microservices are seen as modern, scalable, future-proof. Monoliths, on the other hand, sound like technical debt and missed opportunities.
The reality is far more nuanced. Over the past years I’ve applied both approaches in very different contexts - from a large open-source data ecosystem for the automotive industry to lean web applications for mid-sized businesses. Here’s what I’ve learned.
Related articles on this topic: Modularer Monolith Zu Microservices Migration and Wann Kubernetes Sinnvoll Ist.
What Microservices Really Cost
Microservices offer real benefits: independent deployment, technological flexibility, the ability to scale individual components. But they also bring significant complexity that is frequently underestimated.
Operational overhead. Each service needs its own deployment pipeline, its own logs, its own health checks, its own monitoring. In a project with over a dozen services - distributed across Kubernetes with Helm charts and ArgoCD - the infrastructure itself is a full-time job. Without an experienced team and mature DevOps practices, this quickly becomes a burden.
Network latency and distributed failures. What is a simple method call in a monolith becomes an HTTP request or a message event. Timeouts, retry logic, idempotency, circuit breakers - all of this must be thought through and implemented. A failure in service A can cascade to service B. Distributed tracing becomes essential.
Data consistency. Each service should own its data store. That means no cross-service transactions. For scenarios where multiple services are involved in a single business operation, you need sagas or similar patterns. This is solvable - but complex.
Development velocity. Spinning up a local development environment with ten services takes time. Integration tests become more involved. Code reviews need to consider API contracts between services.
When Microservices Make Sense
This doesn’t mean microservices are wrong. On the open-source project for the automotive industry I contributed to for several years, a microservice architecture was the right call - because:
- Different teams (at different companies) needed to work independently on different services
- The individual components (portal, policy hub, SSI credential issuer, authority registry) had clear, stable domain boundaries
- Different services had genuinely different scaling requirements
- Operations were designed for Kubernetes/AWS from the start, with a dedicated platform team in place
Microservices fit well when you’re already organized along service lines - Conway’s Law works in both directions.
When a Monolith is the Better Choice
For most mid-sized business application projects I work on, a monolith - or better, a modular monolith - is the better starting point.
Why? Because requirements are often not well-understood enough early on to draw meaningful service boundaries. If you slice services too early, you’ll likely slice them wrong - and pay heavily for refactoring later.
A monolith enables:
- Faster initial development velocity
- Simpler debugging and tracing
- Atomic transactions without saga complexity
- Lower infrastructure costs
The Modular Monolith as a Middle Ground
My preferred approach for new projects: the modular monolith. A single deployment artifact, but with clearly defined modules that communicate through interfaces - not directly via database access or static method calls.
The beauty of this: if specific modules later genuinely need independent scaling or deployment, they can be extracted into real microservices with manageable effort. Module boundaries become service boundaries.
In .NET, this looks like: separate modules as class library projects, each with their own domain, application layer, and infrastructure. The host project wires everything together through dependency injection. No module accesses another module’s DbContext directly.
A Decision Framework
Some questions I ask myself on new projects:
| Question | Microservices | Monolith |
|---|---|---|
| Different teams on different parts? | ✓ | - |
| Significantly different scaling requirements? | ✓ | - |
| Clear, stable domain boundaries? | ✓ | - |
| Experienced DevOps team in place? | ✓ | - |
| Fast time to market matters most? | - | ✓ |
| Requirements still in flux? | - | ✓ |
| Team smaller than 5-8 people? | - | ✓ |
If most criteria point toward a monolith: start as a modular monolith. You can always split later. Going the other direction is significantly harder.
Conclusion
Microservices are not a quality badge. They’re a solution to specific scaling and organizational problems - which you may not yet have.
The modular monolith offers a pragmatic middle ground: clear structure without the operational complexity of microservices. For many projects, it is the right starting point - with the option to split specific modules if and when there’s a real reason.
Planning a new project and unsure which architecture fits? Get in touch - happy to talk through your situation.
Related reading
If this topic is relevant for your roadmap, these articles are a good next step: