Strangler Fig Pattern

Overview

The Strangler Fig pattern is an incremental migration strategy for replacing legacy systems without the risk of a big-bang rewrite. Coined by Martin Fowler in 2004, the pattern is named after strangler fig trees -- tropical plants that germinate in the canopy of a host tree, send roots down to the ground, and gradually envelop the host until it is completely replaced.

In software, the host tree is the legacy monolith. The strangler fig is a set of new microservices that are built around the monolith, one domain at a time, until the monolith handles zero traffic and can be safely decommissioned.

This pattern is the dominant approach to monolith decomposition in the industry:

• Amazon -- decomposed its monolithic bookstore into hundreds of services
• Netflix -- migrated from a monolithic Java application to a microservices architecture
• Shopify -- incrementally extracted services from its Ruby on Rails monolith
• Uber -- moved from a single Python application to a polyglot microservice platform
• Etsy -- gradual migration from a PHP monolith to a service-oriented architecture

Architecture

Client Layer

Web and mobile clients send requests over HTTPS. Clients are completely unaware of backend architecture changes -- the migration is invisible to them.

Strangler Proxy / Facade

A proxy (API gateway, reverse proxy, or load balancer) sits in front of both the monolith and the new microservices. It intercepts every request and consults a route table to decide where to forward it. As migration progresses, routes are flipped from the monolith to the corresponding microservice one by one.

Legacy Monolith

The original application that handles all domains in a single deployable unit with a shared database. It starts by handling 100% of traffic and gradually handles less as domains are extracted.

New Microservices

Each extracted domain (Users, Products, Orders) becomes an independent service with its own dedicated database. Services are built, tested, and switched over incrementally.

Data Synchronization (CDC)

During the coexistence phase, Change Data Capture (CDC) tools like Debezium stream changes from the monolith database to the new service databases in real-time, ensuring data consistency while both systems are running.

Key Concepts

Three Phases: Transform, Coexist, Eliminate

The migration follows three phases. Transform: build the new microservice alongside the monolith. Coexist: run both systems in parallel, with the proxy routing traffic to the appropriate destination. Eliminate: once all traffic is routed to the new service and verified, remove the corresponding code and data from the monolith.

Proxy-Based Routing

The strangler proxy is the central mechanism. It maintains a route table that maps URL patterns to backend services. Migrating a domain is as simple as updating a route: /api/users/* changes from MONOLITH to USER_SERVICE. The proxy makes the switch atomic and invisible to clients.

Data Synchronization and CDC

During migration, the same data may need to exist in both the monolith database and the new service database. CDC (Change Data Capture) captures row-level changes from the monolith database and replicates them to the new service database in real-time. This ensures both systems see consistent data during the coexistence phase. Once the route is fully switched, CDC replication is stopped and the data is cleaned up from the monolith.

Shadow Traffic and Dark Launching

Before switching a route, the proxy can send shadow (dark) traffic to the new service: requests are forwarded to both the monolith and the new service simultaneously. The monolith response is returned to the client while the new service response is compared for correctness. This validates the new service under real production load without any risk to users.

Risk Mitigation and Rollback

At any point during migration, the route table can be switched back to the monolith. There is no point of no return until the monolith code is actually deleted. This makes every migration step individually reversible, unlike a big-bang rewrite where rollback means abandoning months of work.

The Anti-Pattern: Big-Bang Rewrite

The Strangler Fig pattern exists specifically to avoid the big-bang rewrite -- the approach where the entire system is rebuilt from scratch and switched over in a single deployment. Big-bang rewrites are notorious for schedule overruns, feature gaps, and catastrophic failures on launch day. The Strangler Fig trades speed for safety: each domain is migrated independently, validated under real traffic, and rolled out with zero downtime.

Migration Lifecycle for a Single Domain

Each domain follows a five-phase lifecycle:

1. Build -- create the new service and its database schema.
2. Sync -- bulk-copy existing data from the monolith and set up CDC for ongoing changes.
3. Verify -- send shadow traffic to both systems and compare responses.
4. Switch -- update the route table to direct real traffic to the new service.
5. Cleanup -- stop CDC replication, drop migrated tables from the monolith, remove dead code.

Scenarios

1. Before Migration -- All traffic flows through the proxy to the monolith. The proxy is deployed as a transparent pass-through, establishing the foundation for incremental migration.
2. During Migration -- Users and Products routes are migrated to new microservices while Orders are still served by the monolith. The proxy routes each request to the correct destination based on the route table.
3. After Migration (Complete) -- All routes point to microservices. The monolith receives zero traffic and is decommissioned. Each service owns its domain and database independently.
4. Migration Step (Detailed) -- Step-by-step process of migrating the User domain: Build the service, sync data via CDC, verify with shadow traffic, switch the route, and clean up the monolith.