System Design · Architecture under constraints
When should you choose microservices over a monolith?
Short answer
Choose microservices when independent deployment, team autonomy or uneven scaling outweigh the cost of distributed systems. Start with a modular monolith when boundaries are still uncertain.
A monolith deploys one application with shared memory and often one database. Microservices split the system into independently deployable services with their own data and lifecycle. The split is an organizational and operational choice as much as a technical one.
What microservices buy
- Independent deploys so one team can release without coordinating everyone
- Independent scaling for components with different load profiles
- Fault isolation when a failure is contained by a service boundary
- Technology choice per service, which is useful only if the team can operate it
- Clear ownership aligned to business capabilities
What they cost
- Network calls replace in-process calls, adding latency and partial failure
- Cross-service workflows need sagas, outboxes and compensation instead of one transaction
- Debugging requires distributed tracing and correlation ids
- Every service needs deployment, monitoring, on-call and versioned contracts
- Data duplication and eventual consistency become normal
The boundary matters more than the count. Split along business capabilities with stable interfaces and data ownership. A split that forces synchronous calls for every read or shares one database creates a distributed monolith: all the operational cost with none of the independence.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is a distributed monolith and how do you avoid it?
- 2How do you decide service boundaries?
- 3Why does a shared database undermine microservices?
- 4When would you extract a module from a monolith?
Say it in the interview
I choose microservices when independent deployment, team autonomy or uneven scaling justify the operational cost. Otherwise a modular monolith is usually the safer start, because boundaries are easier to change before they become network contracts. Microservices bring partial failure, distributed transactions and tracing requirements, so I split along business capabilities with clear data ownership. A shared database or synchronous call chain everywhere is just a distributed monolith.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.