Parallel running in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start the new service alongside the old one.

Microservices

new_service[1]();

Drag options to blanks, or click blank then click option'

Astart

Bstop

Crestart

Dpause

Attempts:

3 left

💡 Hint

Common Mistakes

Using stop() instead of start() causes the service not to run.

Using restart() stops the old service first, not parallel.

To run services in parallel, the new service must be started without stopping the old one immediately.

2fill in blank

medium

Complete the code to route traffic to both services during parallel running.

Microservices

router.addRoute('/api', [1]);

Drag options to blanks, or click blank then click option'

Acache

Bnew_service

Cold_service

DloadBalancer

Attempts:

3 left

💡 Hint

Common Mistakes

Routing only to old_service or new_service defeats parallel running.

Using cache does not distribute traffic.

A load balancer distributes requests between old and new services during parallel running.

3fill in blank

hard

Fix the error in the code to ensure both services run without conflict.

Microservices

if (old_service.status() == 'running' [1] new_service.status() == 'stopped') new_service.start();

Drag options to blanks, or click blank then click option'

Axor

Bor

Cand

Dnot

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'or' starts new_service even if old_service is not running.

Using 'not' or 'xor' causes logical errors.

Using 'and' ensures the new service starts only if the old service is running, enabling parallel running.

4fill in blank

hard

Fill both blanks to correctly implement traffic splitting and monitoring.

Microservices

traffic_manager.setStrategy([1]); monitor.enable([2]);

Drag options to blanks, or click blank then click option'

Acanary

Blogging

Cmetrics

DblueGreen

Attempts:

3 left

💡 Hint

Common Mistakes

Using blueGreen for traffic splitting here is less gradual than canary.

Using logging instead of metrics misses performance data.

Canary strategy gradually shifts traffic; metrics monitoring tracks performance during parallel running.

5fill in blank

hard

Fill all three blanks to complete the parallel running deployment steps.

Microservices

deploy([1]); monitor.[2](); if (monitor.status() [3] 'healthy') { old_service.stop(); }

Drag options to blanks, or click blank then click option'

Anew_version

Bstart

C==

Drollback

Attempts:

3 left

💡 Hint

Common Mistakes

Using rollback instead of deploy breaks deployment flow.

Using '!=' instead of '==' causes wrong condition check.

Deploy the new version, start monitoring, and check if status equals 'healthy' before stopping old service.

Practice

1. What is the main purpose of parallel running in microservices?

easy

A. To run old and new systems together to ensure smooth transition

B. To replace the old system immediately without testing

C. To run only the new system and discard the old one

D. To run multiple unrelated services in parallel

Solution

1. Step 1: Understand the concept of parallel running

   Parallel running means running old and new systems side by side to compare their outputs and ensure the new system works correctly.

2. Step 2: Identify the purpose in microservices

   This approach helps catch errors and ensures a smooth transition before fully switching to the new system.

3. Final Answer:

   To run old and new systems together to ensure smooth transition -> Option A

4. Quick Check:

   Parallel running = run old and new systems together [OK]

Hint: Parallel running means running old and new systems side by side [OK]

Common Mistakes:

• Thinking parallel running means immediate replacement
• Confusing parallel running with running unrelated services
• Assuming old system is discarded immediately

2. Which of the following is the correct way to implement parallel running in a microservices upgrade?

easy

A. Deploy new microservice version alongside old one and route a copy of requests to both

B. Stop old microservice and deploy new one immediately

C. Deploy new microservice and ignore old service logs

D. Run new microservice only during off-peak hours

Solution

1. Step 1: Understand deployment in parallel running

   Parallel running requires both old and new versions to run simultaneously to compare results.

2. Step 2: Identify correct routing method

   Routing a copy of requests to both versions allows output comparison without disrupting users.

3. Final Answer:

   Deploy new microservice version alongside old one and route a copy of requests to both -> Option A

4. Quick Check:

   Parallel running = deploy both and route requests to both [OK]

Hint: Route requests to both old and new services in parallel [OK]

Common Mistakes:

• Stopping old service before testing new one
• Ignoring logs from old service
• Running new service only at specific times

3. Consider a microservice system where requests are sent to both old and new versions during parallel running. If the old service returns response A and the new service returns response B, what should the system do?

medium

A. Ignore the difference and continue using the new service

B. Switch back to the old service permanently

C. Stop the old service immediately

D. Log the difference and alert engineers for investigation

Solution

1. Step 1: Understand output comparison in parallel running

   Parallel running compares outputs to detect discrepancies between old and new services.

2. Step 2: Decide action on output mismatch

   If outputs differ, the system should log the difference and alert engineers to investigate before switching fully.

3. Final Answer:

   Log the difference and alert engineers for investigation -> Option D

4. Quick Check:

   Output mismatch = log and alert [OK]

Hint: Log and alert on output differences during parallel running [OK]

Common Mistakes:

• Ignoring output differences
• Stopping old service too early
• Switching back permanently without investigation

4. A team implemented parallel running but noticed that the new service never receives any requests. What is the most likely cause?

medium

A. The new service crashed immediately after deployment

B. The routing logic is only sending requests to the old service

C. The old service is not logging requests

D. The new service is slower than the old one

Solution

1. Step 1: Analyze routing in parallel running

   For parallel running, requests must be routed to both old and new services simultaneously.

2. Step 2: Identify why new service gets no requests

   If new service never receives requests, routing likely sends all traffic only to old service.

3. Final Answer:

   The routing logic is only sending requests to the old service -> Option B

4. Quick Check:

   No requests to new service = routing issue [OK]

Hint: Check routing logic if new service gets no requests [OK]

Common Mistakes:

• Assuming new service crashed without checking logs
• Blaming old service logs
• Thinking speed affects request routing

5. You are designing a parallel running strategy for a microservices system with high traffic. Which approach best balances safety and performance?

hard

A. Route 100% of traffic to new service and keep old service idle

B. Run new service only during low traffic hours without output comparison

C. Route 10% of traffic to new service and 90% to old service, compare outputs, then gradually increase new service traffic

D. Stop old service immediately and monitor new service logs

Solution

1. Step 1: Understand gradual traffic shifting in parallel running

   Gradually increasing traffic to the new service while comparing outputs reduces risk and performance impact.

2. Step 2: Evaluate options for safety and performance

   Routing a small portion initially and increasing after validation balances safety and system load.

3. Final Answer:

   Route 10% of traffic to new service and 90% to old service, compare outputs, then gradually increase new service traffic -> Option C

4. Quick Check:

   Gradual traffic shift with output comparison = safe and performant [OK]

Hint: Start small traffic to new service, compare, then increase [OK]

Common Mistakes:

• Switching 100% traffic immediately
• Skipping output comparison
• Stopping old service too early