What is the Strangler Fig pattern?
Put a routing layer (proxy or gateway) in front of the legacy system. Build a new service for one slice of functionality, route that slice's traffic to it, and delete the old code once nothing uses it. Repeat until the monolith has nothing left to do.
What problem does the Strangler Fig pattern solve?
Big-bang rewrites take years, deliver nothing until the end and often fail. An incremental migration ships value early, limits risk to one slice at a time, and can be rolled back by changing a route.
How do you implement the Strangler Fig pattern?
- Pick a slice with a clear seam and meaningful value, ideally not the most entangled one first.
- Insert a routing layer in front of the monolith so you can redirect traffic per route or per user group.
- Build the new service and decide how data is handled: sync from the monolith, or move ownership with an anti-corruption layer that translates between old and new models.
- Route a small share of traffic, compare results with the old path, then increase.
- Remove the old code and repeat with the next slice.
When should you use it?
- A legacy monolith is in production and cannot be frozen while you rewrite it.
- You want to deliver improvements during the migration, not after.
When should you avoid it?
- The system is small enough to rewrite in a few weeks.
- There is no clean seam where traffic can be intercepted.
What do you gain?
- Low risk and reversible
- Value is delivered continuously
- Teams learn the new platform on small slices
What does it cost?
- You run two systems for a long time
- Data synchronisation is hard and easy to underestimate
- The routing layer becomes critical infrastructure
What are common mistakes with the Strangler Fig pattern?
- Never finishing, so the monolith lives on forever next to the services.
- Letting the new service read the monolith's database directly, which recreates a shared database.
- Having no way to roll back a route when the new service misbehaves.
Strangler Fig in practice
Airbnb
Airbnb's Rails monolith, Monorail, had grown hard to deploy. Engineers were losing roughly 15 hours a week to reverts and rollbacks.
Airbnb routed client requests through an API gateway and moved functionality into services in phases. Each slice started with about 1% of traffic, compared results against the monolith, and ramped up until the comparison was clean at 100%. Writes were compared against a shadow database.
Source: Airbnb's migration from monolith to SOA (InfoQ, 2019, on Jessica Tai's QCon SF 2018 talk)
Example decision record
- Context
- The monolith cannot be rewritten in one release without unacceptable risk to the business.
- Decision
- Put a gateway in front of the monolith and move routes to new services one slice at a time.
- Consequences
- No long feature freeze on the existing system.
- Data must be kept in sync between old and new stores during the transition, for example with CDC.