Replacing a monolith without a big-bang rewrite
Rewrites stall, budgets balloon and the old system keeps changing underneath you. The strangler pattern lets you modernise one seam at a time while the business keeps trading.
The big-bang rewrite is the most expensive way to discover you didn't understand the old system. Two years in, the new platform covers 70% of features, the old one has gained 40 new ones, and the cutover date keeps moving.
The strangler pattern in practice
Put a routing layer in front of the monolith. Carve out one capability, build it as a new service, and route its traffic to the new service. Repeat. The monolith shrinks until it can be switched off, or until what remains isn't worth replacing.
Choosing the first seam
- High business pain: it's where outages or slow change hurt most
- Clear boundaries: few synchronous calls into the rest of the monolith
- Measurable outcome: latency, uptime or deploy frequency you can show the board
For a typical online retailer, checkout is often the obvious first seam: it fails at peak, it's the most valuable flow, and its inputs (cart, price, stock) can be served from read replicas and events.
The safety net
- Characterisation tests that capture what the old system actually does, bugs included
- Shadow traffic: send real requests to the new service and compare responses
- Percentage-based rollout behind feature flags, with instant rollback
The takeaway
Modernisation that delivers value every month survives budget reviews. Modernisation that promises value in two years usually doesn't.
- Architecture
- Modernisation
- Monolith
