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

Practice

1. What is the main goal of an incremental migration plan in microservices?

easy

A. To avoid testing during migration

B. To rewrite the entire system at once

C. To remove all old services immediately

D. To move functionality step-by-step to reduce risk

Solution

1. Step 1: Understand migration goals

   Incremental migration aims to reduce risk by breaking changes into small steps.

2. Step 2: Compare options

   Options B, C, and D involve big changes or skipping testing, which increase risk.

3. Final Answer:

   To move functionality step-by-step to reduce risk -> Option D

4. Quick Check:

   Incremental migration = step-by-step safe moves [OK]

Hint: Think small safe steps, not big risky jumps [OK]

Common Mistakes:

• Assuming migration happens all at once
• Ignoring the need for testing
• Believing old services must be removed immediately

2. Which of the following is a correct step in an incremental migration plan?

easy

A. Deploy all new microservices simultaneously without routing changes

B. Use feature flags or routing to direct some traffic to new services

C. Stop the old system before starting migration

D. Skip monitoring during migration to save resources

Solution

1. Step 1: Identify safe deployment practices

   Using feature flags or routing allows gradual traffic shift to new services safely.

2. Step 2: Eliminate unsafe options

   Deploying all at once, stopping old system early, or skipping monitoring are risky.

3. Final Answer:

   Use feature flags or routing to direct some traffic to new services -> Option B

4. Quick Check:

   Routing traffic gradually = safe migration [OK]

Hint: Use routing or flags to control traffic flow [OK]

Common Mistakes:

• Deploying everything at once
• Stopping old system too early
• Ignoring monitoring during migration

3. Consider this migration step code snippet for routing traffic:

if (user.isBetaTester) {
  routeToNewService();
} else {
  routeToOldService();
}

What will happen if a user is not a beta tester?

medium

A. User traffic is dropped

B. User traffic goes to the new service

C. User traffic goes to the old service

D. User traffic causes an error

Solution

1. Step 1: Analyze the condition

   If user.isBetaTester is false, the else branch runs.

2. Step 2: Determine routing for else branch

   The else branch calls routeToOldService(), so traffic goes to old service.

3. Final Answer:

   User traffic goes to the old service -> Option C

4. Quick Check:

   Non-beta users = old service routing [OK]

Hint: False condition triggers else branch routing [OK]

Common Mistakes:

• Assuming all users go to new service
• Thinking traffic is dropped or errors occur
• Ignoring the else branch logic

4. A team started migrating a service incrementally but suddenly disabled monitoring. What is the likely problem?

medium

A. They lose visibility into errors and performance

B. They can detect issues faster

C. Migration speed increases without risks

D. Old services automatically update

Solution

1. Step 1: Understand monitoring role

   Monitoring helps detect errors and performance issues during migration.

2. Step 2: Assess impact of disabling monitoring

   Without monitoring, the team loses visibility into problems, increasing risk.

3. Final Answer:

   They lose visibility into errors and performance -> Option A

4. Quick Check:

   No monitoring = no error visibility [OK]

Hint: Never disable monitoring during migration [OK]

Common Mistakes:

• Assuming disabling monitoring improves speed
• Thinking old services update automatically
• Believing issues are easier to detect without monitoring

5. You plan to migrate a monolith to microservices incrementally. Which approach best ensures minimal downtime and rollback capability?

hard

A. Deploy new microservices behind a feature flag and route a small % of traffic gradually

B. Replace the monolith entirely in one deployment window

C. Migrate database schema all at once without backward compatibility

D. Disable old services immediately after deploying new ones

Solution

1. Step 1: Evaluate migration strategies

   Deploying behind feature flags and routing small traffic allows gradual testing and rollback.

2. Step 2: Compare risks of other options

   Replacing all at once or disabling old services causes downtime; schema changes without compatibility break systems.

3. Final Answer:

   Deploy new microservices behind a feature flag and route a small % of traffic gradually -> Option A

4. Quick Check:

   Feature flags + gradual traffic = safe migration [OK]

Hint: Use feature flags and gradual traffic shift for safety [OK]

Common Mistakes:

• Trying big-bang replacement causing downtime
• Ignoring backward compatibility in database changes
• Disabling old services too early