// Architecture Styles · 10
Strangler Fig
Grow the new system around the old one until the old one is gone.
How it fits together
- Browser uses / calls Reverse proxy (all requests)
- Reverse proxy uses / calls Invoices service (/api/invoices)
- Reverse proxy uses / calls Legacy app (everything else)
- Invoices service uses / calls Legacy DB (reads/writes)
- Legacy app uses / calls Legacy DB
Spot it
- A big-bang rewrite keeps getting postponed
- Nobody dares touch the legacy core
- New features still land in old code
It costs
Two systems run side by side for a long time, with routing and data sync to maintain.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
Named after a vine that grows around a host tree until it stands on its own. A facade intercepts traffic; slice by slice, routes move to the new system, and old code is deleted once nothing calls it.
Each step is small, shippable and reversible, which is why it beats a big-bang rewrite that must reach parity before delivering anything. It struggles when the legacy system cannot be intercepted, or when data is so entangled that no slice can own its own.
The target is often a modular monolith or microservices, with an anti-corruption layer keeping legacy concepts out of the new model. Stop when what remains is cheaper to leave than to move.
Ask for it
- routing facade
- reverse proxy
- incremental migration
- anti-corruption layer
- feature parity
- decommission
Put a reverse proxy in front of the legacy app. Route /api/invoices to a new service and everything else to the old system, keep the legacy database as the source of truth until cut-over, and make rollback a routing change.