Monolith vs Microservices
A practical comparison of monolithic and microservice architectures — coupling, deployment, scaling, team context — and how to choose between them.
A monolith is a single application (running on one or many machines) where all computation lives in one deployable unit. A microservice architecture divides the whole workload into business units, each becoming an independent service with its own data and deployment.
Neither is “better” — they optimize for different failure modes of software teams.
Side-by-Side
| Dimension | Monolith | Microservices |
|---|---|---|
| Moving parts | Few | Many |
| Fit | Small teams, early stage | Larger orgs, independent domains |
| Duplication (tests, tooling) | Less | More per service |
| Speed | Faster — in-process procedure calls | Network calls (RPC) per interaction |
| Deployment | Complex — everything touches everything | Independent per service |
| Blast radius | One bug can break everything | Isolated to one service |
| Coupling | Tight | Loose (by contract) |
| Scaling | Scale the whole thing | Scale exactly what’s hot |
| Context needed to work | Whole codebase | One service at a time |
| Design effort | Lower upfront | Tougher — boundaries must be right |
Monolith
Advantages: fewer moving parts; great for small teams; less duplicated test/tooling infrastructure; fast because everything runs in the same box.
Disadvantages: working on anything requires more context; deployments are complex and risky; too much responsibility concentrated in one server — one bad change can break everything; tight coupling makes evolution slow.
Microservices
Advantages: easy to scale individual services; less context needed per developer; parallel development across teams; resources can be allocated where load actually is.
Disadvantages: tougher to design — service boundaries, data ownership, inter-service contracts, and distributed-systems failure modes all become your problem.
How to Choose
- Start monolith until domain boundaries are proven. Splitting later is far easier than un-splitting wrong boundaries.
- Interview framing: most interview questions assume high scale, so microservices are the expected answer — but say why (independent scaling, team autonomy) and acknowledge the operational price.
- The migration path is usually: monolith → extract the hot/critical path as a service → repeat. See Microservices Architecture Patterns for decomposition strategies once you do split.
Part of the Architecture Patterns series.
Related Notes
Microservices Architecture Patterns
Essential patterns for designing, deploying, and operating microservices: decomposition, communication, data management, and operational patterns.
Event-Driven Architecture
Communicating through immutable, persisted events — replayability, idempotency, event sourcing, CQRS, and the trade-offs of eventual consistency.
HLD vs LLD
The difference between high-level design (system architecture, modules, interactions) and low-level design (classes, APIs, database schemas, implementation logic).