Microservices have spent a decade as the answer to every architecture question. The reality is more specific: they solve a particular class of problem that most teams do not have yet.
The monolith-vs-microservices question is worth answering precisely, because the wrong call in either direction is expensive. Staying monolithic when you need independence costs velocity. Splitting prematurely costs years of operational overhead on problems that did not exist.
This guide covers both architectures honestly — what each solves, what each costs, and a concrete framework for deciding which is right for your team and system right now.
What Is a Monolith?
A monolith is an application deployed as a single unit. All functionality — user interface, business logic, data access — runs in one process. When you deploy, you deploy everything together.
This is not an insult. A monolith is the natural starting architecture for most products, and it is the right architecture for many mature ones. The word only acquired a negative connotation when microservices evangelism framed it as the opposite of progress.
A well-structured monolith:
- Has clear internal module boundaries even though it deploys as one unit
- Is fast to develop and debug (no network hops between domains)
- Is simple to test (a single process with no distributed state)
- Has atomic transactions across all domains (a single database, full ACID guarantees)
- Has low operational overhead (one deployment, one health check, one monitoring target)
The problem is not the monolith itself. The problem is the unstructured monolith — where boundaries erode over time, every module imports from every other module, and changes in one area break things in another. This is the real pain most teams are fleeing when they migrate to microservices.
What Are Microservices?
A microservices architecture splits functionality into independently deployable services, each responsible for a specific business domain. Services communicate over a network — typically HTTP/REST, gRPC, or asynchronous message queues.
Each service:
- Has its own deployment pipeline and can be released independently
- Owns its own data store (no shared database)
- Can use a different technology stack from other services
- Can be scaled independently
What microservices genuinely solve:
- Team scaling. Multiple teams can own separate services and deploy without coordinating with each other.
- Independent scaling. A high-traffic service can scale without scaling the whole system.
- Fault isolation. A failure in one service does not necessarily cascade to all others.
- Technology diversity. A payment service can use Go for performance while a reporting service uses Python for ML libraries.
What microservices do not solve:
- Poor domain modelling — a badly bounded service is just a distributed module with all the original problems plus network latency.
- Code quality issues — those follow the boundaries you draw.
- Slow builds in a monolith — that is a tooling and compilation problem, not an architecture problem.
The Real Costs of Microservices
The benefits are well documented. The costs are under-stated.
| Cost | Detail |
|---|---|
| Network latency | Every cross-service call adds network round-trip time. A user request that touched 3 functions in a monolith now makes 3+ HTTP calls, each with timeout and retry logic. |
| Distributed debugging | A failure that produces a single stack trace in a monolith now requires distributed tracing across multiple services and log aggregation across multiple streams. |
| Data consistency | No shared database means no ACID transactions across services. Eventual consistency patterns (sagas, outbox pattern) add significant complexity to flows that touch multiple domains. |
| Operational overhead | Each service needs its own CI/CD pipeline, container image, health checks, alerting, and on-call runbook. 10 services = 10× the operational surface. |
| Testing complexity | End-to-end testing requires all services to be running. Contract testing (Pact, etc.) adds tooling and discipline to maintain. |
| Infrastructure cost | Kubernetes or equivalent is required at a production level. This is non-trivial to set up and maintain. |
Side-by-Side Comparison
| Dimension | Monolith | Microservices |
|---|---|---|
| Deployment unit | Single binary or artifact | One per service |
| Team coordination | High (shared codebase) | Low (independent ownership) |
| Local development | Simple | Complex (need to run multiple services) |
| Debugging | Simple stack trace | Distributed traces across services |
| Data consistency | ACID transactions | Eventual consistency or saga pattern |
| Independent scaling | No | Yes |
| Technology flexibility | Single stack | Per-service stack |
| Operational overhead | Low | High |
| Time to first deployment | Fast | Slow (platform setup first) |
| Best team size | 1–15 engineers | 15+ engineers, multiple teams |
The Modular Monolith: The Middle Ground Most Teams Miss
Before jumping to microservices, there is an intermediate architecture that gives most of the ownership benefits at a fraction of the operational cost: the modular monolith.
A modular monolith is a single deployable unit whose code is structured into clearly bounded modules — each owning its own domain logic, data access, and public interface — with strict rules preventing cross-module imports. Think of it as microservices with the network removed.
What you get:
- Clear domain ownership and boundaries (teams can own modules)
- No network latency between modules
- Full ACID transactions across domains when needed
- Simple local development and debugging
- A single deployment pipeline
- A clear migration path to true microservices when you need them (extract one module at a time)
When a modular monolith is the right choice:
- Your team is growing but not yet hitting real coordination bottlenecks
- You have identified domain boundaries but not yet different scaling requirements
- You want to invest in architectural clarity without taking on operational overhead
- You are planning eventual microservices decomposition and want bounded contexts defined first
Many of the engineering teams with the best developer experience and fastest delivery velocity are running modular monoliths, not microservices. The pattern is under-appreciated.
Decision Framework: Which Architecture Is Right Now?
Answer these six questions. Each one is a signal. No single signal is definitive — but the pattern they form usually makes the answer clear.
Signal 1: Team size and structure
| Team | Signal |
|---|---|
| < 8 engineers, single team | Monolith |
| 8–20 engineers, one or two teams | Modular monolith |
| 20+ engineers, multiple teams with distinct domains | Evaluate microservices |
Signal 2: Deployment frequency and coupling
Are all your domains always deployed together? If yes, is that coupling natural (they always change together) or forced (you have to coordinate even when they don't)? Forced coupling with high-frequency deploys is a strong signal for microservices.
Signal 3: Scaling economics
Do different domains need to scale at materially different rates? If your API handles 10k RPS and your PDF renderer handles 10 RPS, independent scaling has real cost impact. If everything scales together, the economics do not support decomposition.
Signal 4: Domain boundary clarity
Can you draw clean seams between business domains where data ownership is distinct? If yes, those seams are candidates for service boundaries. If domain logic is heavily entangled and data is shared everywhere, extract and clarify the boundaries in a modular monolith first — microservices will not fix entanglement, they will just put network calls between the entangled pieces.
Signal 5: Operational maturity
Do you have Kubernetes (or equivalent), distributed tracing (Jaeger, Tempo, Datadog APM), centralised log aggregation, independent CI/CD pipelines per service, and the on-call coverage to support multiple independent services? If not, build that platform first or budget it into the decision. Microservices without this platform are harder to operate than a well-run monolith.
Signal 6: Technology diversity requirements
Is there a genuine case for different technology stacks in different domains — for example, a Python ML inference service alongside a Go API? If yes, microservices enable this. If the whole team uses the same stack and there is no technical reason for diversity, this signal is neutral.
How to Migrate From a Monolith to Microservices
If the signals above point toward decomposition, the migration path matters as much as the destination.
The strangler fig pattern is the standard approach. The name comes from a plant that grows around an existing tree, gradually replacing it. Applied to software:
- Identify a bounded context — a business domain with clear boundaries and a contained data set.
- Build a new service for that context.
- Route traffic to the new service via an API gateway or proxy, while the monolith's code path still exists as a fallback.
- Validate the new service under production traffic.
- Remove the old code path from the monolith.
- Repeat.
This avoids big-bang rewrites, lets you validate each extraction independently, and keeps the system in a continuously deployable state throughout the migration.
What to extract first: Start with a domain that is:
- Well-bounded (minimal data sharing with other domains)
- Low criticality (not the payment or authentication core)
- A natural fit for different scaling or technology requirements
Payment processing, authentication, and core product domains should come later, after the process is validated.
For teams managing this migration while running production systems, preview environments for each microservice — the pattern covered in our Production-Like Dev Environments with Garden guide — are critical for maintaining development velocity during the transition.
The Honest Summary
Choose a monolith if:
- You are building a new product or have fewer than 15 engineers
- Domain boundaries are unclear or entangled
- You do not have the operational platform for microservices
- Delivery speed is the primary constraint
Choose a modular monolith if:
- You have clear domain boundaries but not yet different scaling needs
- You want architectural clarity without operational overhead
- You are preparing for eventual decomposition
Choose microservices if:
- Multiple teams are blocked on each other in the same codebase
- Different domains genuinely need to scale at different rates and that difference is significant in cost
- You have the operational platform and team maturity to sustain it
- Bounded contexts are clear and data ownership is separable
The pattern we see most often is teams adopting microservices to solve coordination and quality problems that are actually caused by unclear domain models and undisciplined codebases. Microservices distribute those problems — they do not fix them.
Fix the model first. Then extract services from the clarity you have built.
For help assessing your current architecture and planning the right path forward — whether that is restructuring a monolith, designing a modular architecture, or planning a decomposition — see our Enterprise Software Development capabilities or get in touch.
If you are building a scalable application from the ground up, our guide on How to Build Scalable Enterprise Applications covers the architectural foundations that apply regardless of whether you choose a monolith or microservices.