Strangler fig pattern in Microservices - Deep Dive

Overview - Strangler fig pattern

What is it?

The Strangler fig pattern is a way to gradually replace an old software system by building a new system around it. Instead of rewriting everything at once, parts of the old system are slowly replaced with new components. Over time, the old system is 'strangled' and eventually removed. This approach helps avoid big risks and downtime.

Why it matters

Without this pattern, replacing a large system can be risky, expensive, and cause long outages. The Strangler fig pattern allows teams to deliver improvements step-by-step, reducing errors and user disruption. It makes modernization manageable and safer, which is crucial for businesses that rely on their software every day.

Where it fits

Before learning this, you should understand basic software architecture and microservices concepts. After this, you can explore related topics like API gateways, service mesh, and continuous delivery pipelines. This pattern fits into the journey of evolving legacy systems into modern architectures.

Mental Model

Core Idea

Replace a legacy system piece by piece by wrapping it with new components until the old system is fully replaced.

Think of it like...

Imagine a strangler fig tree growing around a host tree. The fig slowly grows and wraps around the host, eventually replacing it without cutting it down all at once.

┌───────────────┐       ┌───────────────┐
│ Legacy System │──────▶│ New System    │
│ (Old Code)    │       │ (New Code)    │
└───────────────┘       └───────────────┘
        ▲                      ▲
        │                      │
        │  Gradual replacement  │
        └──────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding legacy system challenges

Concept: Legacy systems are old software that can be hard to change or maintain.

Legacy systems often have outdated technology, unclear code, and tight coupling. Changing them risks breaking important features. Teams hesitate to rewrite them fully because it can cause downtime and high costs.

Result

You recognize why replacing legacy systems is difficult and risky.

Understanding the pain points of legacy systems explains why gradual replacement is safer than a full rewrite.

2

Foundation

Basics of incremental system replacement

Concept: Replacing a system in small parts reduces risk and allows continuous operation.

Instead of rewriting everything, teams replace one feature or module at a time. Each new part works alongside the old system until it fully takes over. This keeps the system running smoothly during changes.

Result

You see how small, manageable changes help avoid big failures.

Knowing that incremental replacement keeps services available helps you appreciate gradual migration strategies.

3

Intermediate

How the Strangler fig pattern works

Concept: The pattern wraps new components around the old system, routing requests to either old or new parts.

A new system is built to handle some functions. Incoming requests are routed to the new system for those functions and to the old system for others. Over time, more functions move to the new system until the old one is unused and can be removed.

Result

You understand the routing and coexistence of old and new systems.

Seeing how routing controls which system handles requests clarifies how gradual replacement is possible without downtime.

4

Intermediate

Role of API gateways and proxies

🤔Before reading on: Do you think the old system must be changed to use the Strangler fig pattern, or can routing happen externally? Commit to your answer.

Concept: API gateways or proxies route requests to old or new systems without changing the old system.

An API gateway acts as a traffic controller. It decides if a request goes to the old system or the new one. This means the old system can stay untouched while new features are added behind the gateway.

Result

You learn how external routing enables smooth migration.

Understanding that routing can be external avoids the misconception that legacy code must be modified upfront.

5

Intermediate

Incremental data migration strategies

🤔Before reading on: Is it better to migrate all data at once or gradually when using the Strangler fig pattern? Commit to your answer.

Concept: Data migration can also be done gradually to keep systems in sync during transition.

Data used by old and new systems can be synchronized using techniques like dual writes or event streaming. This ensures both systems have consistent data until the old one is retired.

Result

You see how data consistency is maintained during migration.

Knowing how to handle data migration prevents data loss and inconsistency during gradual system replacement.

6

Advanced

Handling dependencies and integration challenges

🤔Before reading on: Do you think all parts of the old system can be replaced independently without affecting others? Commit to your answer.

Concept: Replacing parts independently requires managing dependencies carefully to avoid breaking the system.

Some modules depend on others, so replacing one part may require changes in connected parts. Teams use techniques like interface abstraction and service contracts to isolate components and reduce impact.

Result

You understand the complexity of breaking down tightly coupled systems.

Recognizing dependency challenges helps plan realistic migration steps and avoid unexpected failures.

7

Expert

Surprising pitfalls and performance impacts

🤔Before reading on: Do you think adding routing layers always improves system performance? Commit to your answer.

Concept: Adding routing and coexistence layers can introduce latency and complexity that must be managed.

While the pattern reduces risk, it can add overhead from extra network hops and complexity in monitoring. Teams must optimize routing, caching, and observability to maintain performance.

Result

You realize the tradeoffs between safety and system efficiency.

Understanding these tradeoffs prepares you to balance reliability with performance in production.

Under the Hood

The Strangler fig pattern works by intercepting requests at a routing layer, such as an API gateway or proxy. This layer decides whether to forward requests to the legacy system or the new system based on the requested functionality. Internally, the new system is developed as independent modules or microservices that gradually replace legacy components. Data synchronization mechanisms keep data consistent across systems during transition. Over time, the routing layer directs all traffic to the new system, allowing the old system to be decommissioned.

Why designed this way?

This pattern was designed to reduce the risks of big-bang rewrites, which often fail or cause downtime. It allows teams to deliver value incrementally and maintain system availability. Alternatives like full rewrites or parallel systems were rejected due to high cost, risk, and complexity. The pattern leverages existing infrastructure and routing to minimize changes to legacy code, making migration feasible for large, complex systems.

┌───────────────┐        ┌───────────────┐        ┌───────────────┐
│ Client       │───────▶│ API Gateway   │───────▶│ New System    │
└───────────────┘        │ (Routing)     │        └───────────────┘
                         │               │
                         │               │
                         │               │
                         │               │
                         │               │
                         │──────────────▶│ Legacy System │
                         └──────────────┘        └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the Strangler fig pattern require rewriting the entire system before deployment? Commit to yes or no.

Common Belief: You must rewrite the whole system before switching to the new one.

Reality: The pattern replaces the system incrementally, running old and new parts side by side.

Why it matters: Believing a full rewrite is needed causes teams to delay improvements and take bigger risks.

Quick: Do you think the old system must be modified to support the Strangler fig pattern? Commit to yes or no.

Common Belief: The legacy system must be changed to work with the new system.

Reality: Routing and integration happen externally, so the old system can remain untouched initially.

Why it matters: Thinking the old system must change upfront can block migration due to fear of breaking legacy code.

Quick: Does adding a routing layer always improve system speed? Commit to yes or no.

Common Belief: Adding routing layers makes the system faster and simpler.

Reality: Routing layers add latency and complexity that must be managed carefully.

Why it matters: Ignoring performance impacts can lead to slow user experiences and harder troubleshooting.

Quick: Can all parts of a legacy system be replaced independently without coordination? Commit to yes or no.

Common Belief: Each module can be replaced independently without affecting others.

Reality: Dependencies often require coordinated changes to avoid breaking functionality.

Why it matters: Underestimating dependencies causes failed deployments and system outages.

Expert Zone

1

The pattern often requires careful versioning of APIs to maintain compatibility during transition.

2

Monitoring and observability must cover both old and new systems simultaneously to detect issues early.

3

Data synchronization strategies vary widely and can be the most complex part of migration.

When NOT to use

Avoid this pattern if the legacy system is small, simple, or can be replaced quickly with minimal risk. In such cases, a full rewrite or lift-and-shift may be more efficient. Also, if the system has tightly coupled components that cannot be isolated, consider refactoring or modularizing first.

Production Patterns

In production, teams use feature toggles combined with the Strangler fig pattern to switch traffic gradually. Blue-green deployments and canary releases help test new components safely. API gateways with dynamic routing rules enable flexible traffic control. Event-driven architectures support data synchronization between old and new systems.

Connections

API Gateway

builds-on

Understanding API gateways helps grasp how routing controls traffic between old and new systems in the Strangler fig pattern.

Continuous Delivery

supports

Continuous delivery pipelines enable frequent, safe deployments of new components during gradual system replacement.

Biological Succession (Ecology)

analogous

The gradual replacement of species in an ecosystem mirrors how the Strangler fig pattern replaces software systems over time.

Common Pitfalls

#1 Routing all traffic to the new system before it is fully ready.

Wrong approach:

API Gateway routes 100% of requests to new system immediately after first module is ready.

Correct approach:

API Gateway routes a small percentage of requests to new system, gradually increasing as confidence grows.

Root cause:

Misunderstanding the incremental nature of the pattern leads to premature cutover and failures.

#2 Modifying legacy system code to integrate new components directly.

Wrong approach:

Changing legacy system internals to call new services before routing layer is established.

Correct approach:

Keep legacy system unchanged initially; use external routing to direct requests to new components.

Root cause:

Fear of adding complexity externally causes risky changes inside legacy code.

#3 Ignoring data synchronization between old and new systems.

Wrong approach:

New system writes data independently without syncing with legacy system during migration.

Correct approach:

Implement dual writes or event streaming to keep data consistent across systems.

Root cause:

Underestimating data consistency needs leads to data loss or corruption.

Key Takeaways

The Strangler fig pattern enables safe, incremental replacement of legacy systems by wrapping new components around old ones.

Routing layers like API gateways play a crucial role in directing traffic between old and new systems without modifying legacy code.

Managing dependencies and data synchronization is essential to avoid breaking functionality during migration.

This pattern balances risk and progress, allowing continuous operation while modernizing software.

Understanding tradeoffs in performance and complexity helps teams implement the pattern effectively in production.