Strangler fig pattern in Microservices - Architecture Diagram

System Overview - Strangler fig pattern

The Strangler Fig pattern helps replace a legacy system gradually by building a new system around it. It routes user requests to either the old system or the new microservices, allowing smooth migration without downtime.

Key requirements include seamless request routing, data consistency, and minimal disruption to users during migration.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +--------------------------+
  |                          |
  v                          v
Legacy System           New Microservices
  |                          |
  v                          v
Legacy Database         New Database
  |
  v
Cache

Components

User

client

End user making requests

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Routes requests to legacy system or new microservices based on routing rules

Legacy System

service

Existing monolithic application serving some requests

New Microservices

service

New modular services gradually replacing legacy functionality

Legacy Database

database

Stores data for legacy system

New Database

database

Stores data for new microservices

Cache

cache

Speeds up data access for both systems

Request Flow - 11 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Legacy System or New Microservices

Legacy System or New Microservices → Cache

Cache → Legacy System or New Microservices

Legacy System or New Microservices → Legacy Database or New Database

Legacy Database or New Database → Legacy System or New Microservices

Legacy System or New Microservices → Cache

Legacy System or New Microservices → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Legacy Database

Impact:Legacy system cannot read or write data; requests routed to legacy system fail or degrade

Mitigation:API Gateway routes affected features to new microservices if possible; cache serves stale data for reads; database replication and failover restore service

Architecture Quiz - 3 Questions

Which component decides whether a request goes to the legacy system or new microservices?

A Load Balancer

B Cache

C API Gateway

D Legacy Database

Design Principle

The Strangler Fig pattern enables gradual replacement of a legacy system by routing requests through an API Gateway that directs traffic to either the old or new system. This approach reduces risk by allowing incremental migration, maintaining service availability, and enabling coexistence of old and new components.

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