Incremental migration plan in Microservices - System Design Exercise

Design: Incremental Migration Plan for Monolith to Microservices

Focus on backend service migration and data handling. Frontend changes and deployment automation are out of scope.

Functional Requirements

FR1: Migrate a large monolithic application to microservices gradually without downtime

FR2: Ensure data consistency during migration

FR3: Allow coexistence of old and new services during transition

FR4: Minimize risk of breaking existing functionality

FR5: Enable rollback to monolith if needed

FR6: Support monitoring and debugging during migration

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent users during migration

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime during migration

NFR4: Data synchronization latency under 5 seconds

NFR5: Migration phases must be reversible

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway or Proxy for routing

Service Registry and Discovery

Database replication or synchronization tools

Message queues for asynchronous communication

Feature flags or toggles

Monitoring and logging systems

Design Patterns

Strangler Fig pattern

Database per service vs shared database

Event-driven architecture

Canary releases and blue-green deployments

Circuit breaker pattern

Reference Architecture

Monolith App
   |          \
   |           \
API Gateway ---> Microservice 1
   |           /
   |          /
Shared Database
   |
Message Queue
   |
Monitoring & Logging

Components

API Gateway

Nginx or Kong

Route requests to monolith or microservices based on migration phase

Monolithic Application

Existing tech stack

Legacy system serving requests not yet migrated

Microservices

Spring Boot / Node.js / Go

New services handling migrated features

Shared Database

PostgreSQL / MySQL

Data store accessed by both monolith and microservices during migration

Message Queue

Kafka / RabbitMQ

Asynchronous communication and data synchronization

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Track system health and debug issues during migration

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to monolith or microservice based on feature flag

3. If microservice handles request, it reads/writes to shared database or publishes events to message queue

4. Monolith and microservices synchronize data via message queue or database replication

5. Monitoring system collects metrics and logs from all components

6. Rollback switches routing back to monolith if issues detected

Database Schema

Entities: User, Order, Product Relationships: - User 1:N Order - Order N:1 Product During migration, both monolith and microservices read/write to shared tables with synchronization via events to keep data consistent.

Scaling Discussion

Bottlenecks

API Gateway becomes a single point of failure or bottleneck

Shared database load increases due to dual access

Message queue overload with synchronization events

Monitoring system overwhelmed by logs and metrics volume

Rollback complexity increases with more migrated services

Solutions

Scale API Gateway horizontally with load balancing and failover

Use database read replicas and partitioning; consider database per service after migration

Partition message queues and use topic filtering to reduce load

Implement log sampling and aggregation to reduce monitoring overhead

Automate rollback procedures and limit migration batch size

Interview Tips

Time: 10 minutes for requirements and clarifications, 20 minutes for architecture and data flow, 10 minutes for scaling and trade-offs, 5 minutes for questions

Emphasize gradual migration to reduce risk

Discuss data consistency challenges and solutions

Explain routing strategies and feature toggles

Highlight monitoring importance during migration

Address rollback and failure handling clearly