Incremental migration plan in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Key Benefit of Incremental Migration

Which of the following is the primary benefit of using an incremental migration plan when moving from a monolithic system to microservices?

A It ensures all microservices share the same database schema from the start.

B It requires rewriting the entire system at once to avoid compatibility issues.

C It eliminates the need for any downtime during migration.

D It allows gradual testing and validation of each microservice before full migration.

💡 Hint

Think about how risk is managed during migration.

Incremental migration allows teams to move parts of the system step-by-step, testing each microservice independently to reduce risk and catch issues early.

❓ Architecture

intermediate

Order of Steps in Incremental Migration

What is the correct order of steps in a typical incremental migration plan from monolith to microservices?

A 1,2,3,4

B 3,1,2,4

C 1,3,2,4

D 2,1,3,4

💡 Hint

Think about logical progression from identification to deployment and validation.

First, isolate a capability, then build the microservice, redirect traffic, and finally monitor to ensure success.

❓ scaling

advanced

Handling Data Consistency During Incremental Migration

During incremental migration, what is the best approach to maintain data consistency between the monolith and new microservices?

A Allow both systems to write independently to the same database tables simultaneously.

B Use event-driven architecture with asynchronous messaging to synchronize data changes.

C Stop all writes to the monolith and only write to microservices during migration.

D Duplicate all data manually after migration completes.

💡 Hint

Consider how to keep systems in sync without blocking operations.

Event-driven asynchronous messaging allows both systems to stay updated without tight coupling or downtime.

❓ tradeoff

advanced

Tradeoff of Incremental Migration vs Big Bang

What is a major tradeoff when choosing incremental migration over a big bang migration?

A Incremental migration takes longer but reduces risk and allows continuous delivery.

B Incremental migration requires no changes to existing code.

C Incremental migration guarantees zero bugs after migration.

D Incremental migration eliminates the need for monitoring after deployment.

💡 Hint

Think about time and risk factors.

Incremental migration is slower but safer, allowing teams to deliver continuously and fix issues early.

❓ estimation

expert

Estimating Capacity Needs During Incremental Migration

If a monolithic system handles 10,000 requests per second and you migrate 20% of its functionality to a new microservice, what is the minimum capacity you should provision for the new microservice to handle peak load safely?

A Only 500 requests per second because microservices are more efficient.

B Exactly 10,000 requests per second since all traffic might shift suddenly.

C At least 2,000 requests per second plus a safety margin (e.g., 25%).

D No capacity needed initially; scale only after monitoring.

💡 Hint

Calculate based on percentage of functionality and add buffer for safety.

20% of 10,000 is 2,000 requests per second; adding a safety margin ensures the microservice can handle spikes.

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