Most enterprises carry at least one system nobody wants to touch and nobody can replace overnight. A full rewrite looks tidy on a slide, but it hides risk until cut-over day, when every undocumented behavior surfaces at once. This is my summary of a walkthrough by the iAastha team on a safer alternative: the strangler fig pattern.
The idea
Martin Fowler described the approach in 2004: gradually create a new system around the edges of the old. Each capability goes through three moves: transform (build the new implementation of one capability), coexist (run old and new behind a routing layer), and eliminate (remove the old path once the new one has earned trust).
The worked example
The article uses a hypothetical account-notification service inside a monolith: password resets, failed-payment alerts and statement-ready messages. Notifications are customer-visible and event-driven, so inputs and outputs are easy to observe and compare, which makes them a good first slice.
Five steps
- Draw the boundary and build the seam. Define the capability in one sentence, agree the contract (input event with a unique ID, output message plus delivery record, and a guarantee that one event never produces two sends), then add a facade that initially sends 100 percent of traffic to the legacy path.
- Plan coexistence. Keep one system of record per data set, avoid dual writes, make everything idempotent, and run the new service in shadow mode before it sends anything.
- Route with a canary strategy. Shift traffic by account cohort rather than random request, so a customer never gets half their alerts from each system. Canary suits moving a capability; blue-green suits releasing new versions of the new service.
- Compare behavior before trusting it. Store both decisions per event and compare meaningful fields such as recipient, channel, template and timing. Sort each mismatch into new-service bug, legacy bug customers rely on, or acceptable difference, and agree pass criteria with the capability owner in advance.
- Retire the old path on purpose. Keep it warm through one full business cycle, then freeze changes, remove the routing fallback, archive historical data and delete the legacy code and jobs.
Takeaway
Shrink the unit of change until each step is small enough to reverse. Old code left "just in case" keeps costing patches, infrastructure and on-call knowledge, so retirement deserves a checklist and an owner.
The full article, including a traffic-routing simulator and the retirement checklist, is on the original post: https://iaastha.com/insights/blog/strangler-fig-pattern-modernize-one-business-capability-at-a-time/
Top comments (0)