27. Monolith vs Microservices
1
The picture to keep in your head2
27.1 What is a monolith?3
27.2 What are a monolith's strengths?4
27.3 What is a modular monolith?5
27.4 What are microservices?6
27.5 What is the real cost of microservices?7
27.6 How do you draw service boundaries?8
27.7 How does service discovery work?9
27.8 Sync vs async calls between services: when to use which?10
27.9 What does "database per service" mean?11
27.10 When should you split?12
Memory card and where the analogy breaks13
Practice: five levels14
Interview questions15
Solutions16
Sources17
Code lab27. Monolith vs Microservices
27.1 What is a monolith?
3 min read+10 XP
The two shapes
In the restaurant: One kitchen does everything. One team, one menu, one set of opening hours. If the kitchen closes, the whole restaurant closes.
In the system: A monolith is an application built and deployed as one unit: one codebase, one build, one process (usually run as many identical copies behind a load balancer, Chapter 6), usually one database. For the bookstore, catalogue, cart, orders, payments, search and recommendations are all modules inside the same application.
Figure: same features, three ways of packaging them.
Two things "monolith" does not mean:
- Not one server. A monolith scales horizontally: 20 identical copies behind a load balancer.
- Not bad code. "Monolith" describes how it's deployed, not how well it's organised. A messy monolith is a big ball of mud; a well-organised one is a modular monolith (27.3).
Memory code: "One kitchen, one menu, one door."