Topic 11.1
Monolith vs Microservices
In one line
One deployable vs many — the decision you must be able to justify BOTH ways.
Think of it like this
A single big joint family kitchen where everyone cooks together (monolith) versus each family having its own separate kitchen (microservices). The joint kitchen is simple until 20 people are cooking at once and step on each other; separate kitchens give freedom but now everyone needs to coordinate dinner time.
Key ideas
- 01
Monolith: one codebase/deployable. Simplest ops, fastest commits, no network failures, one transaction boundary.
- 02
Modular monolith: one deployable, strongly modular packages — the honest sweet spot for most teams.
- 03
Microservices: independent deploy/scale/ownership; each service has its own DB (per-service schema).
- 04
Price of microservices: network calls (latency+failures), distributed transactions, data consistency (eventual), debugging across hops, duplicated infra.
- 05
When microservices win: team ownership at 20+ engineers, independent scaling, independent releases, polyglot needs.
- 06
Interview rule: argue for the monolith first for a greenfield 10-person team — then show what forces the split (scale, team, release cadence).
Explain without notes
A startup says 'we're doing microservices' with 6 engineers. Give them the honest alternative and the trigger to switch.
Practice
List the first three services you'd cut out of a growing monolith and the dependency rule that keeps them decoupled.
Trade-offs
- ↔
Teams and scale are the only honest reasons to go distributed; novelty is not one.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can defend a monolith AND describe the trigger that makes microservices worth it.