Strangler Pattern

A migration strategy where a new system gradually replaces a legacy one by intercepting and redirecting requests.

The Strangler pattern is a migration strategy where you build a new system alongside the old one, gradually redirecting functionality until the legacy system can be removed. Instead of a risky big-bang rewrite, you replace one piece at a time.

The name comes from strangler fig trees that grow around a host tree, eventually replacing it entirely. In software, the "strangler" is a facade that sits in front of both the old and new systems. All incoming requests go through it.

At first, the facade delegates everything to the legacy system. Then, feature by feature, you move logic to the new system. The facade starts routing some requests to the new code while others still go to the old. Over time, the legacy system handles fewer and fewer requests until it can be safely decommissioned.

This approach works well with event-driven architectures. You can have the facade publish events when actions happen, and the new system subscribes to those events. The outbox pattern helps ensure reliable event publishing during the transition. The old system doesn't need to know about the new one.

The main benefit is risk reduction. Each step is small and reversible. If the new system has a bug, you can route traffic back to the old one. You don't need to migrate all data upfront. Both systems can coexist for as long as needed.

The trade-off is maintaining two systems in parallel, which adds operational complexity. But for legacy systems that can't be rewritten overnight, it's one of the safest migration strategies available.