Why gradual migration reduces risk in Microservices - Design It to Understand It

Design: Gradual Migration in Microservices

Focus on migration strategy and risk reduction techniques. Out of scope: detailed microservice implementation or specific technology stacks.

Functional Requirements

FR1: Migrate a monolithic application to microservices step-by-step

FR2: Ensure system remains functional during migration

FR3: Minimize downtime and user impact

FR4: Allow rollback of changes if issues occur

FR5: Enable testing of new microservices independently

Non-Functional Requirements

NFR1: Support at least 10,000 concurrent users during migration

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime during migration

NFR4: Data consistency must be maintained between old and new systems

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Router for traffic splitting

Service Registry for discovery

Message queues for asynchronous communication

Database synchronization or dual writes

Monitoring and logging tools

Design Patterns

Strangler Fig pattern

Canary releases

Blue-Green deployment

Feature toggles

Circuit breaker pattern

Reference Architecture

Monolith System
   |
   | Gradual Migration
   v
+-------------------+       +-------------------+
| Old Monolith      |<----->| API Gateway       |
+-------------------+       +-------------------+
                                |          |
                                |          v
                                |    +-------------------+
                                |    | New Microservice 1 |
                                |    +-------------------+
                                |
                                v
                           +-------------------+
                           | New Microservice 2 |
                           +-------------------+

Components

API Gateway

Nginx, Kong, or custom proxy

Route requests to old monolith or new microservices based on migration progress

Old Monolith

Existing monolithic application

Serve requests not yet migrated

New Microservices

Docker containers, Kubernetes

Handle migrated functionality independently

Database Synchronization

Dual writes, change data capture

Keep data consistent between old and new systems

Monitoring & Logging

Prometheus, ELK stack

Track system health and detect issues early

Request Flow

1. Client sends request to API Gateway.

2. API Gateway decides to route request to old monolith or new microservice based on migration phase.

3. If routed to new microservice, it processes request independently.

4. Both old and new systems write to synchronized databases to maintain data consistency.

5. Monitoring tools collect logs and metrics from all components.

6. If issues detected, rollback to old monolith by changing routing rules in API Gateway.

Database Schema

Entities remain consistent across old and new systems. Dual writes or event sourcing ensure data synchronization. Key entities include User, Order, Product with relationships preserved. Migration may involve splitting monolithic tables into microservice-specific schemas.

Scaling Discussion

Bottlenecks

API Gateway becomes a single point of failure or bottleneck.

Data synchronization overhead increases latency.

Rollback complexity if data diverges.

Monitoring large distributed systems is challenging.

Solutions

Use multiple API Gateway instances with load balancing and failover.

Implement eventual consistency with conflict resolution strategies.

Design rollback procedures with data reconciliation tools.

Use centralized logging and distributed tracing for observability.

Interview Tips

Time: Spend 10 minutes understanding migration goals and risks, 15 minutes designing gradual migration architecture, 10 minutes discussing scaling and rollback strategies, 10 minutes answering questions.

Explain why migrating gradually reduces risk by limiting blast radius.

Discuss routing strategies to split traffic safely.

Highlight importance of data consistency and rollback plans.

Mention monitoring to detect issues early.

Show awareness of scaling challenges and solutions.

Practice

1. Why is gradual migration preferred when moving from a monolithic system to microservices?

easy

A. It eliminates the need for testing after migration.

B. It speeds up the migration by doing everything at once.

C. It reduces risk by allowing small, testable changes.

D. It requires no changes to the existing system.

Solution

1. Step 1: Understand the risks of big changes

   Big changes done all at once can cause failures and downtime.

2. Step 2: See how gradual migration helps

   Breaking changes into small steps allows testing and fixing early, reducing risk.

3. Final Answer:

   It reduces risk by allowing small, testable changes. -> Option C

4. Quick Check:

   Gradual migration = smaller risk [OK]

Hint: Small steps mean fewer surprises and easier fixes [OK]

Common Mistakes:

• Thinking migration is faster if done all at once
• Believing testing is unnecessary during migration
• Assuming no system changes are needed

2. Which of the following is a correct practice during gradual migration to microservices?

easy

A. Remove the old system immediately after starting migration.

B. Deploy all microservices at once without testing.

C. Skip monitoring to save resources during migration.

D. Migrate one service at a time and test thoroughly.

Solution

1. Step 1: Identify correct migration practices

   Gradual migration means moving one part at a time with testing.

2. Step 2: Evaluate options

   Only migrating one service at a time and testing fits gradual migration best.

3. Final Answer:

   Migrate one service at a time and test thoroughly. -> Option D

4. Quick Check:

   One service + test = gradual migration [OK]

Hint: Migrate and test one service at a time [OK]

Common Mistakes:

• Deploying all services simultaneously
• Ignoring monitoring during migration
• Removing old system too early

3. Consider this migration plan code snippet:

services = ['auth', 'payment', 'order']
migrated = []
for s in services:
    migrate_service(s)
    migrated.append(s)
    if not test_service(s):
        rollback_service(s)
        break
print(migrated)

What will be the output if test_service('payment') returns False?

medium

A. ['auth', 'payment']

B. ['auth', 'payment', 'order']

C. []

D. ['auth']

Solution

1. Step 1: Trace migration and testing

   'auth' migrates, appends to migrated, tests OK. 'payment' migrates and appends to migrated.

2. Step 2: Rollback and break loop

   On test failure for 'payment', rollback happens but 'payment' was already appended, then loop breaks.

3. Final Answer:

   ['auth', 'payment'] -> Option A

4. Quick Check:

   Appends before test, so includes failed service [OK]

Hint: Stop migration on test failure, rollback last service [OK]

Common Mistakes:

• Thinking failed service is not added to migrated list
• Ignoring append before test
• Continuing migration after failure

4. A team tries to migrate microservices gradually but faces downtime during migration. What is the most likely mistake?

medium

A. They did not maintain backward compatibility during migration.

B. They migrated services one by one with testing.

C. They monitored the system during migration.

D. They rolled back failing services immediately.

Solution

1. Step 1: Understand downtime causes in gradual migration

   Downtime often occurs if new services are incompatible with old ones.

2. Step 2: Identify mistake

   Not maintaining backward compatibility breaks communication causing downtime.

3. Final Answer:

   They did not maintain backward compatibility during migration. -> Option A

4. Quick Check:

   Compatibility issues cause downtime [OK]

Hint: Keep old and new services compatible to avoid downtime [OK]

Common Mistakes:

• Assuming testing alone prevents downtime
• Ignoring backward compatibility
• Believing monitoring causes downtime

5. You are designing a gradual migration plan for a large e-commerce system. Which approach best reduces risk while ensuring continuous service?

hard

A. Migrate all payment-related services first, then all user services, without fallback.

B. Migrate one microservice at a time with automated tests and fallback mechanisms.

C. Switch completely to microservices overnight to avoid prolonged complexity.

D. Disable monitoring during migration to improve performance.

Solution

1. Step 1: Analyze migration strategies

   Migrating all services of one type at once risks big failures; overnight switch is risky.

2. Step 2: Evaluate best practice

   One service at a time with tests and fallback reduces risk and keeps system running.

3. Final Answer:

   Migrate one microservice at a time with automated tests and fallback mechanisms. -> Option B

4. Quick Check:

   Small steps + tests + fallback = low risk [OK]

Hint: One service, test, fallback = safe migration [OK]

Common Mistakes:

• Migrating large groups without fallback
• Doing full overnight switch
• Disabling monitoring during migration