The strangler fig pattern replaces a legacy system piece by piece: a facade routes some traffic to new services while the rest still reaches the monolith, and the old parts shrink until nothing is left. Each step is shippable and reversible, which avoids the risk of a big-bang rewrite.
Before you start
You should understand routing, data ownership and service boundaries. This article is conceptual.
Step-by-step walkthrough
Step 1: Put a routing facade in front
Introduce a facade or gateway that can send a request to either the monolith or the new service based on the route. This lets you migrate one capability at a time and shift traffic gradually, including a canary percentage.
Step 2: Migrate one capability at a time
Move a coherent slice with a clear boundary, such as search or notifications, to a new service, and route its traffic there. Keep the slice small enough to deliver and roll back quickly, and verify behavior against the monolith during the transition.
Step 3: Cut the data tie deliberately
Do not leave the new service reading the monolith’s tables, or the coupling that motivated the split remains. Move data ownership per slice, using dual writes or events with a reconciliation period, then stop the monolith writing that data.
Worked scenario
The facade routes one slice while the rest stays on the monolith.
client -> facade
/search -> new search-service (migrated)
/orders -> monolith (not yet migrated)
/billing -> monolithWalk through the example
/search is handled by the new service while the other routes still reach the monolith, so the search migration ships independently and can be rolled back by reverting the route. Over time more routes move and the monolith handles less, until it can be retired.
Common mistake
Sharing the monolith’s database with new services, which keeps them coupled and prevents independent deploys. Another is attempting a full rewrite before shipping anything, which delays value and concentrates risk.
Verify the behavior
Run the new service and the monolith side by side behind the facade and compare responses for the migrated slice. Canary a small traffic percentage and check error rates before widening. Confirm the new service no longer reads the monolith’s tables after the cutover.
Interview exercise
Why is incremental migration safer than a rewrite?
Answer and reasoning
Incremental steps ship and can be rolled back independently, so a regression affects one slice and is quick to revert. A rewrite delivers nothing until the end and concentrates all risk at the cutover, where subtle behavior differences surface at once. The facade lets you verify each slice against the running system instead of trusting a full replacement.
Continue learning
Compare boundaries in Monolith migration and Data ownership. Read the Strangler fig application and try the Microservices interview questions.