Strangler Fig

Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services 

When to use this pattern?  

• Gradually migrating a back-end application to a new architecture. 

When NOT to use this pattern?  

• When requests to the back-end system cannot be intercepted.  

• For smaller systems where the complexity of wholesale replacement is low. 

The strangler pattern allows the gradual migration from a legacy system to a new one. While the anti-corruption layer we just looked at is useful for communication between the two systems, the strangler pattern is meant for providing services from both to the outside world.

Early in the migration process, the strangler facade will route most of the requests into the legacy system. During the migration, more and more calls can be forwarded into the new one, while strangling the legacy system more and more, limiting the functionality it offers. As the final step of the migration, the strangler, along with the legacy system, can be retired – the new system will now provide all the functionality:

Considerations  

• Consider how to handle services and data stores that are potentially used by both new and legacy systems.  

• Structure new applications and services in a way that they can easily be intercepted and replaced in future strangler fig migrations.  

• At some point, when the migration is complete, the strangler fig façade will either go away or evolve into an adaptor for legacy clients.  

• Make sure the façade keeps up with the migration.  

• Make sure the façade doesn't become a single point of failure or a performance bottleneck.