Bird
Raised Fist0
Microservicessystem_design~25 mins

Strangler fig pattern in Microservices - System Design Exercise

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Legacy System Modernization using Strangler Fig Pattern
Design focuses on the migration approach using the Strangler Fig pattern, including routing, service decomposition, and data handling. Out of scope are specific legacy system internals and detailed microservice implementations.
Functional Requirements
FR1: Gradually replace parts of a legacy monolithic system with new microservices
FR2: Ensure the system remains fully functional during migration
FR3: Route user requests to either legacy or new services based on feature availability
FR4: Minimize downtime and risk during transition
FR5: Allow incremental testing and deployment of new components
Non-Functional Requirements
NFR1: Support up to 5,000 concurrent users during migration
NFR2: API response latency p99 under 300ms
NFR3: Availability target of 99.9% uptime during migration
NFR4: Legacy system cannot be fully rewritten or stopped at once
NFR5: New microservices must integrate smoothly with existing data sources
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
API Gateway or Router for request routing
Legacy monolith application
New microservices for replaced features
Shared database or data synchronization layer
Monitoring and logging tools
Design Patterns
Strangler Fig pattern for incremental migration
API Gateway pattern for routing
Circuit Breaker pattern for fault tolerance
Database per service or shared database strategies
Canary releases and feature toggles
Reference Architecture
          +-------------------+          
          |   Client Apps     |          
          +---------+---------+          
                    |                    
          +---------v---------+          
          |    API Gateway    |          
          +---------+---------+          
           /                   \        
+----------v----------+  +-----v-------+ 
| Legacy Monolith     |  | New Services | 
| (existing system)   |  | (microservices) |
+---------------------+  +-------------+ 
           \                   /        
          +-------------------+          
          | Shared Database or |          
          | Data Sync Layer    |          
          +-------------------+
Components
API Gateway
Nginx or Kong
Routes client requests to legacy or new microservices based on URL or feature flags
Legacy Monolith
Existing system technology stack
Handles requests for features not yet migrated
New Microservices
Spring Boot / Node.js / Go microservices
Implements new or migrated features independently
Shared Database or Data Sync Layer
PostgreSQL / Kafka for event sync
Ensures data consistency between legacy and new services during migration
Monitoring and Logging
Prometheus, Grafana, ELK Stack
Tracks system health and migration progress
Request Flow
1. Client sends request to API Gateway
2. API Gateway checks routing rules or feature flags
3. If feature is migrated, route request to new microservice
4. If feature is not migrated, route request to legacy monolith
5. Microservice or legacy system processes request and accesses database or data sync layer
6. Response is sent back through API Gateway to client
7. Monitoring tools collect metrics and logs for analysis
Database Schema
Entities include User, Order, Product, etc. Initially stored in legacy monolith's database. New microservices may have own databases or share legacy DB with careful synchronization. Data sync layer ensures eventual consistency between old and new data stores during migration.
Scaling Discussion
Bottlenecks
API Gateway becomes a single point of failure or bottleneck
Data consistency issues between legacy and new services
Legacy system performance limits overall throughput
Complex routing logic increases latency
Monitoring overhead impacts system performance
Solutions
Deploy API Gateway in a highly available cluster with load balancing
Use event-driven data synchronization and eventual consistency models
Incrementally refactor legacy system components to microservices
Simplify routing rules and use caching where possible
Optimize monitoring frequency and use sampling to reduce overhead
Interview Tips
Time: Spend 10 minutes understanding requirements and constraints, 15 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 10 minutes for questions and clarifications.
Explain the gradual migration approach and why it reduces risk
Describe how API Gateway routes requests based on feature availability
Discuss data synchronization challenges and solutions
Highlight fault tolerance and fallback mechanisms
Show awareness of scaling bottlenecks and mitigation strategies

Practice

(1/5)
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