Scalability & Architecture Patterns
Microservices vs Monolith
A monolith deploys as one unit and scales by replicating the whole thing; microservices split a system into independently deployable services, trading operational simplicity for the ability to scale, deploy, and own each piece independently.
- A monolith is one deployable artifact — simple to develop, test, and deploy locally; it scales by running more full copies of everything
- Microservices decompose along business capability boundaries — each service owns its data and can be deployed, scaled, and even rewritten independently
- The cost of microservices is distributed-systems complexity: network calls where there used to be function calls, partial failure, and eventual consistency across service boundaries
- A well-factored monolith — clear module boundaries, no shared mutable state across modules — captures most of microservices' organizational benefits without the network overhead
- Team topology often drives the decision more than technology: microservices let independent teams ship independently; a monolith requires more central coordination as team count grows
- The "distributed monolith" antipattern — services split apart but still deployed in lockstep and sharing a database — gets all of the network overhead with none of the independence benefit
| Monolith | Microservices | |
|---|---|---|
| Deployment | one unit, all at once | independent, per service |
| Scaling granularity | whole application | per service, matched to its own load |
| Data ownership | shared schema | each service owns its data |
| Failure isolation | a bug can take down everything | a failing service can be isolated |
| Operational overhead | low — one thing to run | high — many services, network, tracing |