Strangler fig pattern in Microservices - System Design Exercise

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