Strangler Fig
Layer 7 · Post 3 of 5
← Previous: Conway's Law → Next: Tail at Scale
Layer 7 — Patterns and problems · Post 117 of 119
Do not rewrite the monolith in one shot. Intercept calls, replace slice by slice, then retire the core.
What you'll learn
Martin's strangler-fig pattern vs the "big bang rewrite"
Facades, routing, and how data migrates without a dual-write forever
When strangling is slower than a boring modularization inside the monolith
The idea in one minute
A strangler fig grows around a tree, the tree dies, the fig stands. Strangler Fig Application (Fowler): new code wraps the old system at the edges (HTTP, messages, UI), steals one capability at a time, until the old core can be cut down.
clients --> facade / proxy
|-- new service (grows)
+-- old system (shrinks each quarter)
You keep one URL the business already trusts. You do not freeze the world for 18 months for Greenfield 2.0.
Why it matters
Rewrites fail because the target moves (Conway, product) and because dual-running without a steal path is dual writes (Post 108) across everything. Interviews: "migrate the monolith" should sound like strangle, not stop shipping.
It is also how you apply cells and BFFs to a brownfield: new cell is the fig; old datacenter is the tree.
How it works
Intercept. A reverse proxy, API gateway, or the monolith itself as a facade that delegates. Feature flags: 1% of GET /catalog to the new service.
One bounded context at a time. Catalog first, then checkout. Each slice needs data: read from old DB (anti-corruption layer), then own the table, then CDC out of the remaining monolith. Avoid "new service, same tables, no ownership" forever — that is a distributed monolith.
Keep old writes going until the new path is proven (SLOs, Post 114). Then stop the old endpoint. Delete code. If you never delete, you did not strangle; you grew a second tree.
Data cutover. Expand-contract: new column/service, dual write briefly with a defined end (or CDC one way), backfill, switch reads, remove old. An endless dual write is the anti-pattern.
UI strangling. New screens in the new app; old screens iframe or reverse-proxy. Same idea.
When not to. A 4-person 20k-line app: modularize in place. The fig has proxy and dual-run tax. Use it when the tree is too big to rewrite and still too live to freeze.
A simple example
Retail monolith: /products, /cart, /checkout, /admin.
Year 1: gateway sends /products to a new catalog service; catalog reads the old DB via a narrow API. Year 1.5: catalog owns products tables; monolith calls catalog for product names. Year 2: delete monolith product code.
Checkout stays until catalog is boring. A big-bang "new commerce platform" in parallel would duplicate admin, auth, and every edge case until someone gives up.
Common mistakes
Strangle in name, rewrite in fact. Two full systems, no intercept, "cut over Saturday." That is a bang.
Facade that contains all the new logic. You built monolith v2 in the proxy. Keep the facade thin.
Never shrinking the old system. Headcount on both forever. Track lines/capabilities retired.
Shared DB as a permanent strategy. Fine as a step; deadly as an end state (coupling, locking, Conway fights).
No rollback. Canary the facade route; keep the old handler until SLO says go.
How this shows up in real systems
Fowler's article — the name everyone uses.
Amazon / Shopify / banks: years-long stranglers around mainframes.
Frontend: microfrontends as UI figs (with Conway tax).
Strangler + CDC: new read models while the monolith remains the writer, then flip.
Recap
Wrap, steal, retire. One slice, one owner, a real delete at the end.
Dual-run is a phase with a deadline, not an architecture.
Next: why "the average is fine" still fails users — tail at scale.
Layer 7 · Post 3 of 5
← Previous: Conway's Law → Next: Tail at Scale
Comments