Strangler fig pattern in Microservices - Scalability & System Analysis

Scalability Analysis - Strangler fig pattern

Growth Table: Strangler Fig Pattern Scaling

Users	System State	Changes
100 users	Legacy monolith handles all requests	Minimal load, no new microservices yet
10,000 users	Initial microservices start replacing parts of monolith	Routing layer added, some services extracted, moderate traffic
1,000,000 users	Most features served by microservices, monolith shrinks	API gateway scales horizontally, microservices scale independently
100,000,000 users	Monolith fully replaced, large microservices ecosystem	Advanced service mesh, global load balancing, data sharding

First Bottleneck

At small scale, the legacy monolith is the bottleneck because it handles all requests and is hard to scale horizontally.

As traffic grows, the routing layer and API gateway can become bottlenecks if not scaled properly.

Eventually, database access shared by monolith and microservices can limit throughput.

Scaling Solutions

• Incremental migration: Gradually replace monolith features with microservices to reduce risk.
• API Gateway: Use a scalable gateway to route requests to microservices or legacy system.
• Horizontal scaling: Add more instances of microservices and gateway to handle load.
• Caching: Cache common responses to reduce load on backend services.
• Database strategies: Use read replicas, sharding, or separate databases per microservice.
• Service mesh: Manage microservice communication efficiently at large scale.

Back-of-Envelope Cost Analysis

Assuming 1M users generate 10,000 requests per second total:

• Requests per second: ~10,000 QPS
• API Gateway instances: 3-5 servers (each handles ~2000-3000 QPS)
• Microservices: scaled independently, each 1-3 servers depending on load
• Database: read replicas to handle ~10,000 QPS, write capacity scaled or sharded
• Bandwidth: 10,000 QPS * 1 KB/request = ~10 MB/s (well within 1 Gbps network)
• Storage: depends on data retention, but microservices can use separate DBs to optimize

Interview Tip

Start by explaining the legacy monolith and its limitations.

Describe how the strangler fig pattern incrementally replaces parts with microservices.

Discuss bottlenecks at each stage and how to scale routing, services, and data.

Highlight trade-offs between risk, complexity, and scalability.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Add read replicas and implement caching to reduce database load before scaling writes or sharding.

Key Result

The strangler fig pattern scales by incrementally replacing a monolith with microservices, shifting bottlenecks from the legacy system to routing and data layers, which are addressed by horizontal scaling, caching, and database replication.

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