Last updated: 21 October 2026
The strangler pattern, also called the strangler fig pattern, is a way to replace a monolithic system with microservices one piece at a time. A routing layer sits in front of the old system and sends each request either to the legacy code or to a new service. As more features move to the new services, the monolith shrinks until it can be switched off, without a single big bang cutover.
For a bank or finance company, that difference matters more than the architecture itself: the old system keeps running while the new one proves itself, and every step can be checked and, if needed, rolled back.
What is the strangler pattern?
The name comes from Martin Fowler, who saw strangler figs in the Queensland rain forest in 2001. The fig grows around a host tree, roots in the ground and eventually stands on its own in the shape of the tree it replaced. Fowler used it as a metaphor for modernising legacy software gradually rather than rewriting it in one go (Martin Fowler, Strangler Fig Application).
In practice, the pattern relies on a facade, sometimes a proxy or API gateway, between clients and the back end. Clients keep using the same interface and do not need to know a migration is under way. The facade decides, request by request, whether the old system or a new service answers (Microsoft Azure Architecture Center, Strangler Fig pattern).
Big bang rewrite vs strangler pattern
There are two broad ways to leave a monolith: rewrite everything and switch over at once, or replace it in steps. The table compares them on the points that usually decide the choice.
| Big bang rewrite | Strangler pattern | |
|---|---|---|
| When value arrives | Only at cutover, often after a long project | With the first migrated feature |
| Risk at go-live | Concentrated in one cutover | Spread across many small releases |
| Rollback | Hard once the old system is retired | Route traffic back to the legacy feature |
| New features during the project | Often frozen while the rewrite catches up | Can ship on the new services as they go live |
| Main cost | Building and testing the whole system up front | Running both systems and the routing layer for a while |
The strangler pattern does not remove cost; it changes its shape. Temporary code that lets old and new parts coexist is part of the price, and Fowler argues it is usually worth paying.
How the strangler pattern works: four stages
Each feature, or bounded context, goes through the same cycle. When one cycle ends, the next feature starts.
1. Identify
- Analyse the monolith and map its bounded contexts: groups of functions and data that belong together.
- Pick the first one to move: small, well understood and valuable enough to prove the approach.
- Find the seams where it can be separated from the rest of the system.
2. Transform
- Build the selected context as a new microservice with its own interface.
- Keep its behaviour the same as the legacy feature, so the switch is invisible to users.
3. Co-exist
- Put the facade in front of both systems and route part of the traffic to the new service.
- Run old and new side by side, compare results and increase the share gradually.
- Keep shared data consistent between the two during the transition.
4. Eliminate
- Once all traffic goes to the new service and nothing depends on the old feature, remove it from the monolith.
- Repeat the cycle with the next context. When the last one moves, retire the monolith and, if it is no longer needed, the facade.
This cycle is why the pattern is sometimes described as transform, co-exist, eliminate.
When the strangler pattern is the wrong choice
The pattern is not always the right answer. Microsoft’s guidance lists cases where it does not fit (Azure Architecture Center):
- Requests to the old system cannot be intercepted, so there is nowhere to put the facade.
- The legacy code cannot be changed and there is no other integration point, such as its database.
- The system is small enough that replacing it outright is simpler.
- The old system has to be fully retired quickly.
Two more questions are worth asking early: can the facade carry the load without becoming a bottleneck, and who owns the data while both systems are live?
Applying the strangler pattern to core banking
Core banking is where the pattern is most useful and hardest to apply. Running a new core module by module alongside the old one is one of the three paths to a modern core, next to a greenfield launch and a full replacement. Done well, it lets a bank move one product line at a time, for example a new lending product, while deposits and payments stay on the existing system.
Three things decide whether it works in a bank:
- One view of the customer and the ledger. While two systems hold accounts, balances and postings must reconcile every day, and someone must own that reconciliation.
- A routing layer the bank controls. Channels, partners and internal systems should call the facade, not the old core directly, so traffic can move product by product.
- Clear boundaries in the new platform. Products, customers, limits and accounting need clean interfaces so each can move on its own.
This is why the approach pairs naturally with composable banking architecture and an API-first core: each capability can be introduced, tested and adopted on its own. Fimple’s platform is API-first and composable, so institutions can adopt selected capabilities and connect them to the systems they already run, rather than replacing everything at once.
Frequently asked questions
What is the strangler fig pattern in microservices?
It is a migration approach in which new microservices gradually take over the functions of a monolithic application. A facade routes each request to either the old system or the new service until the monolith is no longer needed.
Why is it called the strangler pattern?
Martin Fowler named it after strangler fig plants, which grow around a host tree and eventually replace it. The new system grows around the old one in the same way.
What is the difference between the strangler pattern and a big bang migration?
A big bang migration replaces the whole system in one cutover. The strangler pattern replaces it feature by feature, so value arrives earlier, risk is spread across smaller releases and each step can be rolled back.
How long does a strangler migration take?
It depends on the size of the system and how many features move in each cycle. Because value arrives with each migrated feature, the useful question is how quickly the first feature can go live, not when the last one moves.
Planning a move off a monolithic core? Talk to Fimple about modernising one product line at a time.
