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.

Practice

1. What is the main goal of the Strangler fig pattern in microservices architecture?

easy

A. To build all new services from scratch before replacing the old system

B. To merge all services into a single monolithic application

C. To run the old and new systems completely separately without integration

D. To gradually replace parts of a legacy system with new services

Solution

1. Step 1: Understand the pattern's purpose

   The Strangler fig pattern is designed to replace legacy systems gradually, not all at once.

2. Step 2: Compare options with the pattern goal

   To gradually replace parts of a legacy system with new services matches the gradual replacement approach, while others describe different strategies.

3. Final Answer:

   To gradually replace parts of a legacy system with new services -> Option D

4. Quick Check:

   Gradual replacement = B [OK]

Hint: Strangler fig means gradual replacement, not all at once [OK]

Common Mistakes:

• Thinking it replaces the whole system at once
• Confusing it with parallel running without integration
• Assuming it merges services into one

2. Which of the following is the correct way to route requests in the Strangler fig pattern?

easy

A. Send requests randomly to either legacy or new system without control

B. Direct all requests to the legacy system until the new system is fully ready

C. Route requests step-by-step from the legacy system to new microservices

D. Stop the legacy system completely before routing any requests

Solution

1. Step 1: Identify routing strategy in Strangler fig

   The pattern routes requests gradually from old to new components, not all at once or randomly.

2. Step 2: Match options with routing approach

   Route requests step-by-step from the legacy system to new microservices describes step-by-step routing, which fits the pattern best.

3. Final Answer:

   Route requests step-by-step from the legacy system to new microservices -> Option C

4. Quick Check:

   Step-by-step routing = A [OK]

Hint: Route requests gradually, not all or random [OK]

Common Mistakes:

• Routing all requests to legacy until full switch
• Routing requests randomly causing inconsistency
• Stopping legacy before new system ready

3. Consider this simplified request flow in a Strangler fig pattern:

Legacy system handles requests for features A, B, C.
New microservice replaces feature A.
Requests for A go to new service; B and C go to legacy.
What happens when a request for feature B arrives?

medium

A. It is routed to the new microservice handling feature A

B. It is routed to the legacy system since B is not replaced yet

C. It causes an error because feature B is missing in new service

D. It is dropped and not processed

Solution

1. Step 1: Analyze routing rules for features

   Only feature A is replaced by the new microservice; B and C remain in legacy.

2. Step 2: Determine routing for feature B request

   Requests for B still go to legacy system as it is not replaced yet.

3. Final Answer:

   It is routed to the legacy system since B is not replaced yet -> Option B

4. Quick Check:

   Feature B not replaced = legacy route = C [OK]

Hint: Unreplaced features stay on legacy system [OK]

Common Mistakes:

• Routing all requests to new service regardless of feature
• Assuming missing features cause errors
• Dropping requests instead of routing properly

4. A team tries to apply the Strangler fig pattern but routes all requests to the new microservice before it fully supports all features. What is the main problem with this approach?

medium

A. It leads to inconsistent behavior as new service lacks some features

B. It causes downtime because legacy system is stopped too early

C. It improves performance by forcing early migration

D. It simplifies deployment by removing legacy dependencies

Solution

1. Step 1: Identify issue with premature routing

   Routing all requests early means new service may not handle all features yet.

2. Step 2: Understand impact on system behavior

   This causes inconsistent or failed responses for unsupported features.

3. Final Answer:

   It leads to inconsistent behavior as new service lacks some features -> Option A

4. Quick Check:

   Premature routing = inconsistent behavior = A [OK]

Hint: Route only supported features to new service [OK]

Common Mistakes:

• Thinking early routing improves performance always
• Assuming legacy can be stopped immediately
• Ignoring feature support gaps

5. You are designing a migration plan using the Strangler fig pattern for a large monolithic app with features X, Y, and Z. Feature X is critical and must have zero downtime. How should you apply the pattern to ensure smooth migration?

hard

A. Replace feature X first with a new microservice and route only X requests there, keep Y and Z on legacy

B. Replace all features at once to avoid partial routing complexity

C. Stop the legacy app and start new microservices for all features simultaneously

D. Keep all features on legacy until new system is fully ready, then switch all at once

Solution

1. Step 1: Prioritize critical feature migration

   Feature X requires zero downtime, so migrate it first carefully.

2. Step 2: Apply gradual routing for feature X only

   Route requests for X to new microservice while Y and Z remain on legacy to reduce risk.

3. Step 3: Avoid full switch or stopping legacy abruptly

   The other options risk downtime or complexity by switching all features at once.

4. Final Answer:

   Replace feature X first with a new microservice and route only X requests there, keep Y and Z on legacy -> Option A

5. Quick Check:

   Gradual critical feature migration = D [OK]

Hint: Migrate critical features first, route requests gradually [OK]

Common Mistakes:

• Trying to replace all features at once
• Stopping legacy before new system ready
• Delaying critical feature migration