The strangler-fig migration pattern is the safest approach to decomposing a monolith into microservices. Named after the strangler fig tree that grows around and eventually replaces its host, the pattern involves building new microservices alongside the existing monolith and gradually routing traffic to the new services — without ever requiring a big-bang cutover or production downtime.
Why Big-Bang Rewrites Fail
The history of big-bang monolith rewrites is a graveyard of failed projects. The fundamental problem: you are building something of equivalent complexity to what you are replacing, without the benefit of years of production edge-case discovery. The strangler-fig pattern avoids this by keeping the monolith running throughout — it never gets turned off until every bounded context has been migrated and proven in production.
Step 1: Identify Bounded Contexts
Before writing a single line of new code, spend 2 weeks documenting your monolith's bounded contexts — the natural domain boundaries within the application. Typical bounded contexts: user identity and authentication, payments and billing, notifications, reporting and analytics, core domain logic. Each bounded context will become one (or more) microservices.
Step 2: Implement Traffic Routing
Traffic routing must happen at the load balancer level — not at the application level. Implement an NGINX or AWS ALB routing layer that can direct traffic to either the monolith or the new microservice based on the URL path or request header. This routing layer is the strangler-fig vine — it gradually takes over the traffic that was previously going to the monolith.
Step 3: Migrate One Context at a Time
Build the first microservice — typically the lowest-risk bounded context — alongside the monolith. Deploy it to production. Route 1% of traffic to the new service. Monitor for errors. Scale to 10%, 50%, 100%. Once 100% of traffic is routing to the new service and it has proven stable for 2 weeks, decommission the corresponding code in the monolith.
Database Migration Strategy
Database migration is the hardest part of the strangler-fig pattern. The key principle: all schema migrations during the transition window must be backwards-compatible (additive-only). New columns can be added but not renamed or removed until the monolith code that references them is fully decommissioned. Use the expand-contract pattern for all schema changes.
Want Brantum to Implement This for You?
We do not just write about this — we implement it. Book a free strategy call and let's discuss how these principles apply to your specific business.
Book a Free Strategy Call