Microservices Patterns : Strangler Fig Pattern
Microservices Design Pattern Part 14 : Evolve Your System Without Breaking It
Strangler Fig
The Problem It Solves
Martin Fowler coined the term in 2004, inspired by the strangler fig tree native to tropical rainforests. The fig’s seeds land in the canopy of a host tree, grow roots downward, and slowly wrap around the host — eventually replacing it entirely. The host disappears, the new tree stands on its own.
That metaphor is exactly what happens during a legacy migration done right.
The alternative is the Big Bang Rewrite — stop the world, rebuild everything from scratch, flip the switch. It sounds clean in a slide deck. In practice it means:
- 12–18 months of parallel development with no new features
- A go-live moment where everything can go wrong at once
- No rollback once deployed
- Business stakeholders losing confidence midway
- Teams that rewrote the system don’t fully understand the implicit behavior of the original
The strangler fig avoids all of this by migrating incrementally, keeping the monolith live while new services take over piece by piece.
Core Mechanics — The Three Phases
Every strangler fig migration follows the same three-phase loop, repeated for each functional slice:
Phase 1 — Identify: Pick a vertical slice of functionality in the monolith. Ideally something with well-defined inputs/outputs, low coupling to other modules, and high business value or high change frequency.
Phase 2 — Intercept: Insert a routing layer (proxy or API Gateway) in front of the monolith. At this point, all traffic still goes to the monolith — but the seam now exists.
Phase 3 — Migrate: Build the new microservice. Once it’s production-ready, update the routing layer to redirect that slice’s traffic to the new service. The monolith code path for that slice goes dormant.
Repeat until the monolith is empty. Then decommission it.
The Facade / Proxy Layer
The routing seam is the most critical structural piece of the strangler fig. Without it, there is no safe migration — you’d have to do a hard cutover, which defeats the purpose.
The facade sits in front of the monolith and acts as a transparent proxy initially. It forwards 100% of traffic to the monolith. As new services come online, routing rules are updated — specific routes redirect to the new service, while everything else still hits the monolith. The client never needs to know anything changed.
In practice this is implemented via:
The key invariant: the facade owns the routing table, not the services themselves. This gives you a single control plane to manage the migration, roll back a service instantly, or run A/B testing between monolith and new service.
Database Migration Coupling
The hardest part of the strangler fig isn’t the code — it’s the database. Monoliths typically have a single shared schema. When you extract a service, you can’t just rip its tables out overnight because the monolith may still read/write those same tables.
There are three progressive stages of database decoupling:
Stage 1 — Shared Database: The new service and the monolith both access the same DB. It’s the lowest friction starting point but creates tight coupling.
Stage 2 — Dual Write: The new service writes to its own DB, and a synchronization layer (or the application itself) ensures the monolith DB stays in sync. This is the critical transition period.
Get Abhinav Thakur’s stories in your inbox
Join Medium for free to get updates from this writer.
Stage 3 — Change Data Capture (CDC): Tools like Debezium stream row-level changes from the monolith DB to the new service’s DB via Kafka or similar. This gives you eventual consistency without modifying the monolith’s write path. Once the new service is stable, the monolith’s writes to those tables stop and the tables are deprecated.
Anti-Patterns to Avoid
Decompose by Business Capability
What Is a Business Capability?
Before drawing service boundaries, you need the right vocabulary. These three terms are constantly confused in interviews:
- Business Capability: What the business does. A stable, permanent ability — “Process Payments”, “Manage Inventory”, “Handle Returns”. Capabilities don’t change when technology or org structure changes.
- Business Function: A group of related activities performed by a team. Closer to an org chart entry.
- Feature: A specific user-facing behaviour in a product. Features are implemented within capabilities.
The distinction matters because features change frequently, org structures change sometimes, but capabilities change almost never. Aligning service boundaries to capabilities gives you the most stable possible decomposition.
Building a Business Capability Map
A capability map is a structured hierarchy that breaks the business down into what it does, not how. For an e-commerce company it might look like this:
Conway’s Law Connection
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations.” — Melvin Conway, 1967
This is not a metaphor — it’s a structural force. If your backend team owns all data access and your frontend team owns all UI, you will get a layered architecture regardless of what the architecture doc says. The team boundaries become the service boundaries.
Decompose by Business Capability deliberately inverts this. Instead of letting org structure dictate system structure, you define the capability map first, then align teams to capabilities. Each team owns one or two L2 capabilities end to end — their service, their database, their deployment pipeline. This is the foundation of Amazon’s “two-pizza team” model and what led to their services-based architecture in the early 2000s.
The practical implication: when you draw your capability map, check whether your current org structure matches it. Mismatches are architectural debt waiting to happen.
Decompose by Business Capability vs. Decompose by Subdomain (DDD)
This is a common interview question. They are related but not identical:
In practice they produce similar boundaries. The difference is the lens: capability decomposition reasons from the org/business; subdomain decomposition reasons from the domain model. Use capability mapping first (it’s faster and stakeholder-friendly), then validate with DDD techniques if the domain is complex.
Common Mistakes
Where Both Converge
Using the Capability Map to Sequence the Strangler
This is where the two patterns become a complete strategy.
The strangler fig tells you how to migrate — incrementally, through a proxy seam, in repeatable loops. But it doesn’t tell you which capability to extract first. That’s where the capability map comes in.
Use this scoring matrix to sequence your migration:
Change Frequency matters because high-churn modules are the ones slowing your team down inside the monolith. Extract those first and you get immediate developer velocity gains.
Coupling Score matters because a highly coupled module is expensive to extract and risky. Start with loosely coupled ones to build team confidence and pattern familiarity before tackling the hard ones.
The Unified Picture
The central thesis of this article is:
Decompose by Business Capability answers “where to cut.”
Strangler Fig answers “how to migrate safely.”
Together they form a complete modernization strategy.
Here’s what the full arc looks like:
Summary
The strangler fig and decompose by business capability are frequently taught as separate patterns but they are most powerful when combined into a single migration strategy.
Start by building your capability map — it forces clarity on what the business actually does, independent of how the current system is organized. Score your capabilities by change frequency and coupling to get a migration sequence. Then insert your proxy facade, and begin extracting one capability at a time, handling the database decoupling at each step.
The result is an incremental, low-risk migration where the monolith shrinks incrementally rather than being rewritten all at once. The business keeps shipping. The team builds confidence with each extraction. And eventually, the host tree disappears entirely — the new architecture stands on its own.
Thank you for reading until the end. Before you go:
- Please consider clapping and following the writer! 👏
- Connect me on LinkedIn
