How to decouple a monolith without downtime?
Context / The Problem
Many growing startups reach a point where their initial monolithic architecture becomes a bottleneck. Deploys take hours, tests are flaky, and any single bug can take down the entire system. But the business can’t afford a two-year “feature freeze” to rewrite everything from scratch.
The Analysis
The mistake most teams make is attempting a “Big Bang” rewrite. They create a v2 architecture on the side, promising it will solve all problems. This almost always fails because business requirements change faster than the rewrite.
The Pragmatic Solution: The Strangler Fig Pattern
Instead of a rewrite, use the Strangler Fig pattern.
- Identify a Domain Boundary: Pick a single, loosely coupled domain within the monolith (e.g., “Notifications” or “Invoicing”).
- Build an API Facade: Put an API Gateway or reverse proxy in front of the monolith.
- Extract the Service: Build the new microservice for that specific domain.
- Route Traffic: Slowly route traffic for that specific domain from the monolith to the new service using the API Gateway.
- Decommission: Once verified, remove the old code from the monolith.
Rinse and repeat. The business continues to function, features can still be added to the monolith if strictly necessary, and the technical debt is paid off iteratively.