Strangler Fig Pattern — Incrementally Migrating from Monolith to Microservices

The idea

Martin Fowler, named after the strangler fig vine that grows around a host tree and eventually replaces it. Core: never rewrite a working system in one big bang.

Big-bang rewrites fail because: scope underestimated, parallel systems must be maintained, cutover high-risk with no rollback, business value pauses during the rewrite.

Strangler fig: route specific URLs to a new service via a facade; rest still hits the monolith. Migrate one piece at a time. Monolith shrinks, new system grows, eventually monolith disappears.

The facade — heart of the pattern

API gateway / reverse proxy / thin Java service in front of the monolith. Routes requests by URL/path/header to either the new service or the legacy monolith.

Clients see one URL regardless of where work happens. Migration is a routing change, not a client change. Without the facade, every client would need to know which URLs go where — unmanageable.

Migration sequence per slice

1. 1
   Identify a slice — single bounded capability, cohesive, clear inputs/outputs, limited cross-references
2. 2
   Add the facade — all traffic still routes to monolith, no behavioral change yet
3. 3
   Build the new service with its own DB and the same external contract as the monolith's endpoints
4. 4
   Sync data — backfill new DB from monolith tables, keep in sync (dual writes / CDC / events)
5. 5
   Shadow traffic — facade sends copies of real requests to new service, compares responses, doesn't return new results yet. Catches regressions safely
6. 6
   Canary cutover — 1% → 5% → 25% → 50% → 100%
7. 7
   Decommission monolith code for that capability
8. 8
   Decommission shared DB tables once monolith no longer needs them

Repeat for next slice. Months to years; monolith shrinks to nothing.

Data ownership — the hardest part

Dual writes: both write to their DBs. Facade or new service writes through to monolith. Risk: partial-write inconsistency; need reconciliation jobs.

CDC (Debezium/Maxwell): stream changes from monolith DB to new service. Monolith remains source of truth during migration. After cutover, reverse direction.

Event-sourcing backfill: if monolith publishes events, replay to populate new DB. Cleanest, rare.

Cutover moment: new service becomes source of truth. Before: monolith owns. After: new service owns. Riskiest moment; plan rollback carefully.

How to pick what to extract first

Pull (reasons to extract): high change frequency, different scaling profile, different language/runtime, new team wants ownership, compliance isolation.

Push (reasons it's safe): few/unidirectional dependencies, clear bounded context (DDD), already has own tables, simple data ownership.

Avoid first: highly entangled core (auth, billing) — do last. Tiny pieces with no value — migration tax overwhelms benefit.

Common first picks: notifications, search, analytics read models, image/file handling — clean boundaries, read-mostly.

Strangler vs big bang

Risk: all-or-nothing at cutover vs incremental rollback per slice Time to first value: 12-36 months vs weeks per slice Feature velocity: frozen or duplicated vs continuous Surprise cost: late and huge vs spread out Likelihood of completion: low vs high

Big-bang rewrites have dismal industry track record. Strangler fig is the responsible default.

Common mistakes

• Reads to new service, writes to monolith, no sync — data drifts
• No facade — routing in clients, redeploy on every step
• Extracting easy things first — doesn't move the needle
• No cutover criteria — 'when ready' is vague; define metrics (error rate, latency p99, shadow parity)
• Skipping shadow traffic — first production cutover finds bugs
• No deprecation plan — old code lingers half-used
• Rewriting business logic during extraction — extract first, improve later

Recommendation

Use the strangler fig pattern for any non-trivial monolith → microservices migration. Put a facade in front, identify a high-value, low-coupling slice (DDD analysis helps), build a new service with the same external contract, sync data via CDC or dual writes, shadow traffic, canary cutover, decommission old code. Pick slices by pull (need for autonomy/scale) and push (low coupling). Never rewrite business logic during extraction — preserve behavior first, improve in a follow-up. Track migration progress with concrete metrics (% traffic on new service, lines of dead monolith code, services with own DB). Big-bang rewrites should be banned by default; strangler fig is the responsible alternative.