Monolith vs microservices
What each architecture is, the real trade-offs, and how to answer the classic interview question.
Monolith vs microservices
Monolith
One codebase, one deployable. All features run in the same process.
- Pros: simple to develop, test, debug and deploy. Calls between parts are fast in-process calls. One database keeps data consistent.
- Cons: you scale everything together. A large codebase gets slow to change and to build. One bad deploy or crash affects every feature.
Microservices
Many small services, each with one job, its own data, and its own deployment. They talk over HTTP or messages.
- Pros: teams deploy independently. You scale only the busy service. A failure can stay inside one service.
- Cons: network calls are slower and can fail, so you need timeouts and retries. Data is spread out, so there is no simple transaction across services. You need logging, tracing, monitoring and automated deployment from day one.
How to choose
| Situation | Better fit |
|---|---|
| New product, small team, changing requirements | Monolith |
| Several teams stepping on each other in one codebase | Microservices |
| One part needs much more scale than the rest | Split out that part |
A popular middle way is the modular monolith: one deployable, but clear internal modules with their own boundaries. Modules can later become services when there is a real reason.
The interview answer
Don’t say one is always better. Say: start with a monolith with clear modules; move a module to its own service when a team or scaling need justifies the extra complexity. Then mention what microservices require: independent data, network resilience, and observability.
Read more: https://roadmap.sh/software-design-architecture
#tip · TIP-061
Write a comment