Strangler Fig Pattern — Monolith to Microservices Migration

The Strangler Fig pattern is the opposite of a big-bang rewrite. You place an API gateway in front of the existing monolith, extract one module at a time into a new service, and route traffic to it at the gateway — the monolith keeps running throughout with no feature freeze, no launch day, and no all-or-nothing risk.

The migration sequence:

• Start with a low-risk, well-bounded module — user profiles or notifications, not payments; build the new service with its own database and API, then update the gateway to route the relevant path to the new service
• If something breaks, one routing change sends traffic back to the monolith — rollback is seconds, not a deployment cycle
• The monolith's code stays intact for at least one release cycle after cutover, so regression is always available

Database migration — the underestimated part:

• Redirecting HTTP routes to a new service that still reads from the monolith's database creates a distributed monolith — the service is independent in name only
• Replicate data via CDC (Debezium), shadow-test reads for at least a week, then switch writes; the new service becomes the authoritative data owner
• The anti-corruption layer translates between the monolith's legacy data model and the new service's clean domain model — without it, you inherit 15-year-old column names and business rules baked into database schema

The test of real independence:

• If you can't deploy the extracted service without coordinating with another team or service, you have a distributed monolith, not microservices

I recommend Strangler Fig as the only safe migration approach — big-bang rewrites fail more than 70% of the time because the second system must achieve full feature parity before delivering any value.