Monolith vs
Microservices
The most debated topic in engineering. Startups rush to microservices and die. Giants cling to monoliths and stagnate. Where is the balance?
Definitions
Monolith
A single deployable unit. All code (Auth, Orders, Payments) runs in the same process, sharing the same memory and database.
Microservices
Small, independent services communicating over a network (HTTP/gRPC). Each has its own database and can be deployed separately.
In Defense of the Monolith
Why you should probably start here
- 1. Simple Deployment:One repo, one CI pipeline, one Docker container.
- 2. Atomic Transactions:
BEGIN... COMMITworks. No distributed sagas needed. - 3. Zero Network Latency:Function calls are nanoseconds. RPC calls are milliseconds.
- 4. Easier Refactoring:Moving code between modules is just copy-paste. No breaking API contracts between teams.
Microservices Reality Check
Microservices solve organizational problems, not technical ones. They allow 500 engineers to work without stepping on toes. But the cost is high.
The Hidden Costs
- Distributed Tracing: Debugging a request across 10 services is a nightmare.
- Eventual Consistency: Data is never consistent everywhere at once.
- Network Failure: What if the Payment service is down?
- DevOps Tax: You need K8s, Service Mesh, specialized infra teams.
"If you can't build a well-structured monolith, what makes you think you can build well-structured microservices?"
— Simon BrownWhen to Split
The Checklist
Migration: The Strangler Fig
How do you move from Monolith to Microservices? Never rewrite from scratch.
Put a Load Balancer / API Gateway in front of the Monolith.
Identify ONE bounded context (e.g., Billing). Build a new Service for it.
Route /billing/* to the new service. Everything else still goes to Monolith.
Repeat until the Monolith is empty (or small enough to be just another service).