Monolith vs microservices.
One big shop where everyone works under one roof, versus a row of specialist stalls that each run themselves.
A monolith is one big shop. Sales, stock, and the kitchen all share the same building, the same till, and the same back room. Everything is close at hand, so things are simple to coordinate, but one fire can take out the whole place.
Microservices split that shop into a row of independent stalls, each run by its own team with its own till. A stall can change its menu or close for repairs without bothering the others. The freedom is real, but now the stalls have to talk across the street to get anything done together.
- Everything under one roof.1
A monolith is one shop: sales, kitchen, and stock all share a roof and a till.
- Hey, grab that for me!2
Talking between parts is cheap — just shout across the room, no walking outside.
- Fire! Everybody out.3
But one kitchen fire can shut the whole place, and you cannot grow just the till.
- My stall, my rules.4
Microservices split it into stalls — each its own team, own till, own hours.
- Back in five — carry on.5
One stall can repaint or close without bothering the rest, and busy ones grow alone.
- You hear me over there?6
The cost: stalls now shout across the street, and a dropped order is on you.
What you really trade
A monolith keeps everything in one process, so calls between modules are plain function calls and there is one database to reason about. The cost shows up as it grows: the codebase gets tangled, every change redeploys the whole thing, and you cannot scale just the slow part.
Microservices buy independence — separate deploys, separate scaling, separate failure — but you pay in network calls between services, distributed data, and a lot more operational machinery to run and observe it all.
Why most teams start monolith
Microservices solve problems you mostly get at scale: many teams stepping on each other, parts of the system needing very different scaling. Reaching for them too early means paying the distributed-systems tax with none of the benefit.
A common path is to start with a well-structured monolith, then peel off services only where a clear boundary and a real scaling or team need appears.