Monolith vs Microservices
Monolith vs microservices explained with trade offs on deployment, scaling, and team size, for system design interviews.
A monolith ships as one deployable unit and is simpler to build and run early on. Microservices split the system into independent services that scale and deploy separately, at the cost of more operational complexity.
Monolith vs Microservices at a glance
| Monolith | Microservices | |
|---|---|---|
| Deployment | One unit, deployed together | Many units, deployed independently |
| Scaling | Scale the whole app, even unused parts | Scale only the service that needs it |
| Team ownership | One codebase, harder to split across teams | Each team can own a service end to end |
| Complexity | Simple to build, test, and deploy early | Needs service discovery, networking, monitoring |
| Failure isolation | One bug can bring down the whole app | A failing service can be isolated from others |
| Best for | Small teams, early stage products | Large teams, systems that need independent scaling |
When to use each
Choose Monolith when
- You are an early stage product validating an idea and speed matters most.
- You have a small team where the overhead of many services is not worth it.
- Your traffic is predictable enough that scaling the whole app together is fine.
Choose Microservices when
- Different parts of your system need to scale independently, like checkout versus search.
- You have multiple teams that need to deploy without blocking each other.
- You want failures in one part of the system to not take down everything else.
Why this question comes up so often
Interviewers ask this because there is no universally correct answer, and how you reason about it tells them how you think about trade offs. A monolith is not automatically bad, and microservices are not automatically good. Most companies actually start as a monolith and split out services only when a specific part of the system needs to scale or be owned by a separate team.
The real cost of microservices
Splitting a system into services adds real overhead. You now need service discovery so services can find each other, network calls where you used to have function calls, and monitoring across many moving parts instead of one. None of that is free, which is why jumping to microservices too early is a common and expensive mistake.
A strong interview answer mentions that many successful companies started as a monolith and split into microservices later, once a specific team or scaling bottleneck justified the added complexity. Saying you would start simple shows maturity.
Frequently asked questions
Should a new startup start with microservices?
Usually not. Most experienced engineers recommend starting with a well structured monolith and splitting out services later, once you have a clear reason like independent scaling or team ownership.
What is a common failure mode of microservices?
A distributed monolith, where services are technically separate but so tightly coupled through synchronous calls that you get all the complexity of microservices with none of the independence benefits.
How do microservices usually communicate?
Common patterns include REST or gRPC calls over HTTP, and asynchronous messaging through a queue or event bus for cases where services should not block on each other.
Want more interview ready comparisons?
Browse every Monolith vs Microservices style breakdown, or explore the full question library.
All comparisons Browse questions