intermediate9 min readUpdated 2026-06-08

Strangler Fig Pattern

The Strangler Fig Pattern incrementally migrates a legacy monolith to microservices by routing traffic to new services one feature at a time, avoiding.

Quick answer: Strangler Fig Pattern

Strangler Fig Pattern is covered here as a practical system design concept. The Strangler Fig Pattern incrementally migrates a legacy monolith to microservices by routing traffic to new services one feature at a time, avoiding. Use it to understand the Architecture Patterns idea, where it appears in production systems, and how to discuss it clearly in interviews.

Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.

Aspect	Details
What it is	An incremental migration strategy that replaces monolith functionality with new services one feature at a time via a routing layer
When to use	Migrating from monolith to microservices, replacing legacy systems, modernizing tech stacks — any situation where big-bang rewrite is too risky
When NOT to use	Small, maintainable monoliths where the cost of migration exceeds the benefit, or when the entire system needs replacing rather than incremental migration
Real-world example	Amazon spent years strangling their monolith into microservices — each team extracted their service one at a time while the monolith continued serving traffic
Interview tip	Describe the routing layer and how it enables gradual cutover without downtime — this shows practical migration experience
Common mistake	Trying to strangle too many features at once — the complexity of maintaining both old and new systems simultaneously is high, so migrate one feature at a time
Key tradeoff	Safety of incremental migration vs the cost of maintaining two systems in parallel during the transition

Why This Matters

Big-bang rewrites fail. The 2001 Netscape rewrite took three years and nearly killed the company. The Strangler Fig Pattern avoids this by allowing the old and new systems to coexist. A routing layer (API gateway or reverse proxy) directs traffic: /api/orders goes to the new order microservice, everything else goes to the monolith. Each migration is small, testable, and reversible. If the new service fails, flip the route back to the monolith. This pattern reduces risk to near zero while delivering incremental business value with each migrated feature.

System architecture diagram for Strangler Fig Pattern showing how services, databases, and caches connect — System architecture for Strangler Fig Pattern

The Building Blocks

Routing Layer: An API gateway or reverse proxy that directs requests to either the monolith or the new service based on URL path, header, or feature flag.
Feature Extraction: Identify a bounded context in the monolith, build it as a new microservice, and redirect its traffic. Start with the least coupled, highest-value feature.
Data Migration: The hardest part. New services need their own data stores, but during transition both old and new may need the same data. Use CDC or dual-writes.
Parallel Running: Run both old and new implementations simultaneously, comparing results to verify correctness before cutting over. This catches subtle bugs.
Decommission: Once all traffic flows to the new service and the monolith code path is unused, delete the old code. Never leave dead code in the monolith.

Under the Hood

The migration follows a cycle: identify, build, route, verify, decommission. First, identify a feature boundary in the monolith that is relatively decoupled — user authentication, order processing, or notification sending. Build the replacement as a standalone microservice with its own database. Configure the routing layer to send a percentage of traffic (1%, then 10%, then 100%) to the new service via canary deployment.

Step-by-step diagram showing how Strangler Fig Pattern processes a request from start to finish — How Strangler Fig Pattern works step by step

The routing layer is the linchpin. In a simple setup, Nginx route rules direct /api/users/* to the new user-service and everything else to the monolith. In a more sophisticated setup, feature flags control per-user routing: internal users get the new service first, then beta users, then everyone. If errors spike, the flag rolls back instantly.

Data migration is the hardest problem. The monolith and new service often need the same data. Strategies include: database view (new service reads from the monolith's database initially — expedient but coupling), CDC (change data capture streams changes from the monolith's database to the new service's database), or dual-write (monolith writes to both databases during transition — risky due to consistency issues). CDC is usually the safest approach.

How Companies Actually Do This

Amazon strangled their monolith over several years in the early 2000s. Each team extracted their service from the monolith, and the API gateway routed traffic gradually. This became the foundation of AWS.

Comparison table for Strangler Fig Pattern contrasting approaches, tradeoffs, and when to use each — Comparing key aspects of Strangler Fig Pattern

Shopify migrated their Ruby on Rails monolith to microservices using the strangler pattern. They extracted services by domain (checkout, inventory, payments) while the monolith continued serving merchants.

Twitter migrated from their Ruby monolith to JVM-based services. The routing layer directed traffic to new services one endpoint at a time while maintaining 99.99% uptime during the multi-year migration.

Common Pitfalls

Attempting to migrate too many features simultaneously — parallel migrations create integration complexity that negates the safety benefits of incremental migration
Not investing in the routing layer — a brittle routing setup makes cutover and rollback difficult and error-prone
Leaving the monolith in a permanent 'half-strangled' state — without commitment to completing the migration, you end up maintaining two systems indefinitely

Data flow diagram for Strangler Fig Pattern showing how requests and responses move through the system — Data flow through Strangler Fig Pattern

Interview Questions Worth Practicing

How would you plan a strangler fig migration for a 10-year-old monolith with 50 features?
What is the hardest problem in strangler fig migrations, and how do you solve it?
How do you handle shared data between the monolith and new microservices during migration?

The Tradeoffs

Safety vs Speed: Incremental migration is low-risk but takes months or years. Big-bang rewrites are faster but have a high failure rate.
Dual Maintenance Cost vs Risk Reduction: Running both systems costs more (duplicate infrastructure, two codebases), but each migration step is independently testable and reversible.
Clean Break vs Coupling: New services that read from the monolith's database are quick to build but create tight coupling. Independent databases are cleaner but require data migration.

Component diagram for Strangler Fig Pattern showing each building block and its responsibility — Key components of Strangler Fig Pattern

How to Explain This in an Interview

Here is how I would explain Strangler Fig Pattern in a system design interview:

The Strangler Fig Pattern migrates a monolith to microservices incrementally — one feature at a time. Instead of a risky big-bang rewrite, I put a routing layer (API gateway) in front of both systems. When I extract user authentication as a new service, the gateway routes /auth/* to the new service while everything else stays on the monolith. I migrate with canary routing: 1% of traffic, then 10%, then 100%, monitoring error rates at each step. If something breaks, roll back the route instantly. The hardest part is data — I use CDC to replicate data from the monolith's database to the new service's database. Each migration is small, testable, and reversible. Amazon used this exact pattern to become the microservices company they are today.

Interview preparation checklist for Strangler Fig Pattern with key points to mention and mistakes to avoid — Interview tips for Strangler Fig Pattern

Original DosiBridge notes for Strangler Fig Pattern

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Strangler Fig Pattern is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

Ownership Boundary: For Strangler Fig Pattern, decide the ownership boundary before choosing tools; otherwise the design looks clean but fails when strangler changes.
Blast Radius: For Strangler Fig Pattern, decide the blast radius before choosing tools; otherwise the design looks clean but fails when pattern changes.
Deployment Path: For Strangler Fig Pattern, decide the deployment path before choosing tools; otherwise the design looks clean but fails when strangler changes.
Runtime Coupling: For Strangler Fig Pattern, decide the runtime coupling before choosing tools; otherwise the design looks clean but fails when pattern changes.
Operational Handoff: For Strangler Fig Pattern, decide the operational handoff before choosing tools; otherwise the design looks clean but fails when strangler changes.

Production review question

If a team adopts Strangler Fig Pattern, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track strangler-pattern health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Strangler Fig Pattern, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.