Strangling the Monolith: Zero-Downtime Migration Patterns

The legacy trap

Most enterprise architectures inevitably calcify. What begins as a neatly organized MVC application slowly degrades into a monolithic dependency web. Teams stop shipping. Builds take hours. Deployment requires weekend war rooms.

The solution is the strangler fig pattern.

Defining the strangler fig

Instead of attempting a "big bang" rewrite, which fails in the large majority of enterprise scenarios, we incrementally replace legacy functionality with new services. We deploy an API gateway to intercept traffic, routing it to either the legacy monolith or the new service based on the URL path or a feature flag.

Step 1: The edge proxy

Before writing a single line of new service code, deploy a strict reverse proxy at the edge. Everything routes to the monolith on day one; the proxy exists so that changing that later is a config change rather than a project.

# envoy.yaml proxy configuration
routes:
  - match: { prefix: "/api/v2/checkout" }
    route: { cluster: "new_checkout_service" }
  - match: { prefix: "/" }
    route: { cluster: "legacy_monolith" }

Step 2: Event interception

Legacy systems often rely on shared database state. To decouple the new service, we implement change data capture, commonly Debezium and Kafka, to stream database row changes from the legacy database into the new service's isolated datastore.

This is what makes the migration reversible. Both systems hold current data, so a route can be moved back to the monolith at any point without a restore.

Conclusion

Migrating a monolith is a marathon of discipline. By prioritizing edge-routing and asynchronous data replication, engineering teams can modernize their stack while keeping the business running at full velocity.

References

• Martin Fowler. StranglerFigApplication, the original description of the pattern.
• Debezium documentation on change data capture connectors.
• Envoy Proxy routing configuration.