What a monolith is
A monolith ships all features as one deployable unit sharing one codebase and usually one database. It is simple to build, test, and deploy early on.
Why teams split it
As the system grows, the monolith strains:
- Scaling is all or nothing, even if only checkout is hot.
- Deploys are risky because one change ships everything.
- Team coupling rises as everyone edits the same code.
Microservices break the system into small, independently deployable services owned by separate teams.
The cost side
Microservices are not free. You trade in process simplicity for distributed systems problems: network failures, partial outages, and data spread across services.
When to move
Move when team and scale pain is real, not on day one. A clean monolith first is usually the right start.
Key idea
Split a monolith when team and scaling pain outweigh the new cost of distributed complexity, not before.