The Strangler pattern is a technique to gradually migrate legacy systems that was popularized with the exponential popularity of microservices. In this pattern, a service acts as a façade that intercepts requests from the clients and routes them to either the legacy service or new services.
Clients continue to use the same interface, unaware of the migration minimizing the possible impact — and the risk of the migration.
Migrating gradually to a new system, while keeping the old system to handle the features that haven’t been implemented is a better path.
But clients need to know about both systems and update every time a feature has been migrated.”
An Application Load Balancer routes clients’ requests to the Orders Service, the first microservice the team implemented. Everything else continues to go to the Legacy application.
Orders has its own data store and implements all the business logic for Orders. Because some of the features on the legacy app use orders, we need to push the data back to the legacy app to stay in sync (an Anti-corruption Layer of sorts).
As the project evolves, new features come in and we create new services.
The Leaderboard Service is now available. It’s a completely new feature that the brand new Engagement Team created so there’s no need to interact with the Legacy app.
Teams will continue to create new features and port existing features to new services. When all the required functionality has been phased out of the legacy monolithic app it can be decommissioned.
The façade keeps evolving side by side with the new services. Some data stores can potentially be used by both new and legacy services. New services should be structured in a way that they can be intercepted easily. At some point, the migration should be complete, and the strangler façade should either go away or evolve into a gateway or an adaptor.
