Strangler Fig Pattern Explained for Developers

What is the Strangler Fig Pattern?

Imagine you have a big, old application. We’re talking monolith. It works, mostly, but it’s a pain to update, slow to deploy, and frankly, nobody understands all of it anymore. You need to modernize, but a complete rewrite is a terrifying prospect. You could lose data, break functionality, and the project might drag on for years.

This is where the Strangler Fig pattern comes in. It’s a strategy for gradually replacing a legacy system with a new one. Think of the strangler fig plant itself. It grows on an existing tree, sending down roots and eventually enveloping the host. Over time, the fig becomes the dominant structure, and the original tree dies off, leaving the fig in its place.

In software, we do something similar. We build new functionality or replace existing pieces piece by piece, routing traffic to the new code instead of the old. Gradually, the old system is “strangled” until it can be retired entirely.

Why Use the Strangler Fig Pattern?

There are several good reasons:

• Reduced Risk: Instead of one massive, high-risk migration, you’re doing many small, low-risk changes. If one piece fails, it’s contained and easier to fix.
• Incremental Value: You start seeing the benefits of your new system sooner. New features can be built on the modern stack, and users can benefit from improvements incrementally.
• No Big Bang: Big bang rewrites are notorious for failure. They often take longer than planned, go over budget, and can still end up with a system that’s hard to maintain.
• Learn As You Go: You learn about the old system’s intricacies as you extract pieces, and you learn best practices for the new system as you build it.
• Continuous Delivery: It allows you to keep delivering value to your users throughout the modernization process.

How Does It Work?

The core idea is to create a facade or proxy that sits in front of your existing application. As you build new services or modules, you route specific requests through this facade to the new implementation. The facade intercepts requests, decides whether to send them to the old system or the new one, and returns the response.

Here’s a common workflow:

1. Identify a Piece to Replace: Pick a small, well-defined piece of functionality in the legacy system that you want to replace. This could be a specific API endpoint, a user interface module, or a backend process.
2. Build the New Implementation: Develop the new functionality as a separate service or module using modern technologies.
3. Introduce a Facade: Set up a proxy or API gateway in front of the legacy system. Initially, this facade just forwards all traffic to the old application.
4. Redirect Traffic: Configure the facade to route requests for the chosen piece of functionality to your new implementation. All other requests still go to the legacy system.
5. Iterate: Repeat steps 1-4 for other pieces of the application. Gradually, more and more traffic will flow through the new system.
6. Retire the Old: Once all critical functionality has been migrated, the legacy system can be safely decommissioned.

A Simple Example (Conceptual)

Let’s say we have a legacy e-commerce monolith with an orders endpoint (/api/orders). We want to move order processing to a new microservice.

Phase 1: Initial Setup

Our API Gateway (the facade) currently just points to the monolith:

1
Request: GET /api/orders
2
Gateway -> Monolith: GET /api/orders
3
Monolith -> Gateway: Order Data
4
Gateway -> Client: Order Data

Phase 2: Introduce New Order Service

We build a new Order Service that handles order creation and retrieval.

Phase 3: Redirecting Requests

We update the API Gateway. Now, when a request comes in for /api/orders, the gateway checks if it’s a POST request (which we’ve migrated). If it is, it goes to the new Order Service. If it’s a GET request, it still goes to the monolith.

1
Request: POST /api/orders
2
Gateway -> New Order Service: POST /api/orders
3
New Order Service -> Gateway: Order Confirmation
4
Gateway -> Client: Order Confirmation
5

6
Request: GET /api/orders
7
Gateway -> Monolith: GET /api/orders
8
Monolith -> Gateway: Order Data
9
Gateway -> Client: Order Data

We continue this process. Eventually, all order-related operations are handled by the new service, and we can remove the old /api/orders endpoint from the monolith.

Tools and Technologies

Common tools to help implement this pattern include:

• API Gateways: Nginx, Kong, Traefik, AWS API Gateway, Azure API Management.
• Service Meshes: Istio, Linkerd (can help with traffic routing and control).
• Reverse Proxies: HAProxy, Envoy.

Conclusion

The Strangler Fig pattern is a powerful, pragmatic approach to modernizing complex, legacy applications. It breaks down a daunting task into manageable steps, significantly reducing risk and allowing for continuous delivery of value. It’s not always the easiest path, but it’s often the smartest one for substantial system overhauls.