Strangler Fig Pattern

The strangler fig pattern is a migration strategy that incrementally replaces components of a legacy system with new services, routing traffic gradually from the old system to the new one until the legacy system can be decommissioned.

What It Really Means

The pattern is named after the strangler fig tree, which grows around an existing tree, eventually replacing it entirely while the host tree decays. In software, you build new functionality alongside the old system, redirect traffic piece by piece, and eventually remove the old system — without a big-bang rewrite.

Big-bang rewrites fail. They take years, the requirements change while you are rewriting, the old system keeps evolving in parallel, and when you finally launch, you discover edge cases the old system handled that nobody documented. The strangler fig pattern avoids this by delivering incremental value. Each extracted component goes to production independently, gets validated with real traffic, and proves its correctness before you move on to the next.

Martin Fowler popularized the term in 2004, but the approach is ancient. Any time you have replaced one part of a system while keeping the rest running, you have used a variant of this pattern. What makes it a formal pattern is the deliberate routing infrastructure that lets you switch traffic between old and new implementations.

How It Works in Practice

The Three Phases

Phase 1: Identify and Extract Choose a slice of functionality to extract. Start with something that has clear boundaries, low coupling to the rest of the system, and high business value. Often this is a read-only API or a self-contained feature.

Phase 2: Build and Route Build the new service that implements the same functionality. Deploy it alongside the old system. Set up a routing layer (reverse proxy, API gateway, or load balancer) that can direct traffic to either the old or new implementation based on configuration.

Phase 3: Validate and Migrate Start routing a small percentage of traffic to the new service. Compare responses. When confidence is high, route 100% of traffic to the new service. Decommission the corresponding code in the old system.

Repeat for the next slice.

Real-World Example: Shopify's Checkout Migration

Shopify migrated their checkout system from a monolithic Rails app to a new architecture. Instead of rewriting checkout entirely:

1. They identified checkout as a bounded context with clear inputs and outputs
2. Built a new checkout service behind a feature flag
3. Routed a small percentage of checkouts to the new service, comparing outcomes
4. Gradually increased traffic as confidence grew
5. Eventually retired the old checkout code from the monolith

At no point was checkout unavailable. Merchants experienced no downtime. If the new service had issues, traffic was instantly routed back to the old system.

Routing Strategies

Path-based routing: The API gateway routes /api/v2/orders/* to the new service and everything else to the monolith.*

Header-based routing: Requests with X-Use-New-Service: true go to the new service. Useful for internal testing before public rollout.

Percentage-based routing: 10% of requests go to the new service, 90% to the old. Gradually increase as you gain confidence.

User-based routing: Specific user segments (internal employees, beta users) use the new service. Everyone else uses the old system.

Implementation

Trade-offs

When to Use the Strangler Fig Pattern

• Migrating from a monolith to microservices
• Replacing a legacy system with a new technology stack
• The existing system is in production and cannot have downtime
• The migration will take months or years — you need incremental delivery
• You want to validate each migrated component with real traffic

When NOT to Use

• The legacy system is small enough for a complete rewrite in a sprint
• The old and new systems have fundamentally different data models that cannot coexist
• There is no way to route traffic between old and new implementations
• The team will not commit to maintaining two systems during the transition

Advantages

• Zero downtime migration — users are unaffected
• Incremental value delivery — each extracted service is independently useful
• Reversible — if the new service fails, route traffic back to the old system
• Risk is spread over many small deployments instead of one big-bang launch

Disadvantages

• Maintaining two systems simultaneously is expensive
• Data synchronization between old and new systems is complex
• The migration can stall — the last 20% of the monolith is often the hardest
• Requires investment in routing infrastructure and feature flags

Common Misconceptions

• "The strangler fig pattern means rewriting everything" — Not all parts of the legacy system need to be replaced. Some stable, well-functioning components can remain. The goal is strategic extraction, not total replacement.

• "You should extract the easiest parts first" — Extract the parts with the highest business value and clearest boundaries first. Easy extractions that provide no business value waste effort and delay meaningful migration.

• "Dual writes are always safe" — Dual writing to both the old and new database introduces consistency challenges. If one write succeeds and the other fails, the systems diverge. Use change data capture (CDC) or event-based synchronization for reliability.

• "The old system does not need maintenance during migration" — The legacy system still needs bug fixes and critical updates during the migration period. Plan for maintenance of both systems.

• "Migration is purely a technical project" — Successful migrations require domain-driven design analysis to find the right boundaries. They also require product management alignment on the migration order and timeline.

How This Appears in Interviews

The strangler fig pattern is directly relevant to system design interviews:

• "How would you migrate this legacy monolith to microservices?" — Describe domain analysis to find boundaries, the strangler fig approach for incremental extraction, and routing strategies. See our system design interview guide.
• "How do you handle data migration between old and new systems?" — Discuss dual writes, change data capture, and eventual consistency.
• "What if the migration stalls halfway?" — Discuss the risk of a permanent hybrid state and strategies to maintain momentum.
• Practice with our migration interview questions.

Related Concepts

• Monolith vs Microservices — The transition the strangler fig enables
• Domain-Driven Design — Finding the right extraction boundaries
• API Gateway Pattern — The routing layer that directs traffic
• Microservices Architecture — The target architecture
• Event-Driven Architecture — Data synchronization during migration
• System Design Interview Guide — Comprehensive preparation
• Algoroq Pricing — Practice migration interview questions