Monolith vs. Microservices
The problem
A system can be built and deployed as one unified codebase, or split into many independently deployable services — each choice trades away real advantages of the other, and picking one without understanding the tradeoff leads to either a monolith that's outgrown its structure or a microservices system paying distributed-systems costs it didn't need yet.
Why now
Coupling and cohesion already gave the vocabulary for judging internal structure; this topic is where that same question gets asked at the deployment boundary, not just the code boundary — and distributed system basics already established that splitting a system across machines introduces real, unavoidable partial-failure costs a single-process monolith never has to pay.
Mental model
A monolith is one deployable unit with strong internal coupling options (a direct function call) and a single failure domain (if it's up, it's all up). Microservices trade that away for independent deployability and scaling — but every function call across a service boundary becomes a network call, inheriting every cost distributed-system-basics already warned about (latency, partial failure) that a monolith's in-process calls never had to consider.
Requires
- Coupling & CohesionSoftware Architecture
Choosing service boundaries in a microservices architecture is a direct, high-stakes application of judging cohesion (does this belong together) and coupling (how much do these need to know about each other) — badly drawn boundaries recreate a monolith's coupling problems across a network instead of removing them.
- Distributed System BasicsDistributed Systems
Splitting a monolith into microservices means every in-process call becomes a network call, inheriting every partial-failure and unreliability cost distributed-system-basics already established as unavoidable — you need those costs in mind to evaluate the tradeoff honestly.
Unlocks
Used in
- Every architecture decision about how to structure a growing system
- Understanding why 'just use microservices' is not automatically the right default
- Migration strategies for splitting a monolith incrementally (the strangler fig pattern)
- Team structure and Conway's Law — service boundaries often mirror organizational boundaries
Projects
- Take a hypothetical monolithic e-commerce system and propose a microservices decomposition, explicitly justifying each service boundary in terms of cohesion
- List three real costs a team would take on by splitting a working monolith into microservices, and three real benefits, for a specific hypothetical team size and scale
Examples
- A small team maintaining a monolith can deploy the entire application with one command; the same team running 15 microservices needs orchestration, service discovery, and distributed tracing just to operate at the same level of confidence
- A poorly decomposed 'microservice' that still requires two other services to be online for basic functionality has recreated tight coupling, just across a slower, less reliable network boundary
Resources
Mastery checklist
- I can list concrete tradeoffs (not just buzzwords) between a monolith and microservices
- I can propose a microservices decomposition for a given system, justifying each boundary
- I can explain why bad service boundaries can be worse than a monolith
- I can judge, for a given team size and scale, whether microservices are likely to be worth their added cost