Lessons from microservices failures - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify the common cause of microservices failure related to network issues.

Microservices

if service_response.status_code == [1]:
    retry_request()

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

A503

B500

C404

D200

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 500 which is a server error but not specifically service unavailable.

503 Service Unavailable indicates the service is temporarily unable to handle the request, often due to network or overload issues.

2fill in blank

medium

Complete the code to implement a retry mechanism with exponential backoff in microservices communication.

Microservices

for attempt in range(max_retries):
    try:
        call_service()
        break
    except NetworkError:
        sleep([1] ** attempt)

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

A2

B3

Cattempt

Dmax_retries

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'attempt' as base causes linear backoff, not exponential.

Exponential backoff commonly uses base 2 to increase wait time exponentially after each retry.

3fill in blank

hard

Fix the error in the circuit breaker pattern implementation to prevent cascading failures.

Microservices

if failure_count > [1]:
    open_circuit()
else:
    call_service()

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

A-1

B5

C100

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using 0 or negative values disables circuit breaker logic.

A threshold like 5 failures is typical to open the circuit and stop calls temporarily.

4fill in blank

hard

Fill both blanks to correctly implement a health check for a microservice.

Microservices

def health_check():
    response = requests.get('[1]')
    return response.status_code == [2]

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

Ahttp://localhost:8080/health

Bhttp://localhost:8080/status

C200

D404

Attempts:

3 left

💡 Hint

Common Mistakes

Using '/status' or expecting 404 as healthy response.

The health endpoint is commonly '/health' and a 200 status code means service is healthy.

5fill in blank

hard

Fill all three blanks to implement a timeout and fallback in a microservice call.

Microservices

try:
    response = call_service(timeout=[1])
except TimeoutError:
    response = [2]()

if response.status_code == [3]:
    process_response(response)

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

A5

Bfallback_service

C200

D10

Attempts:

3 left

💡 Hint

Common Mistakes

Using too high timeout or wrong status code.

Timeout is set to 5 seconds, fallback_service is called on timeout, and 200 status means success.

Practice

1. Which of the following is a key lesson from microservices failures to improve system resilience?

easy

A. Design services to be loosely coupled and handle failures gracefully

B. Combine all services into a single monolith to avoid communication issues

C. Ignore monitoring since failures are rare and unpredictable

D. Avoid retries to prevent additional load on services

Solution

1. Step 1: Understand microservices failure causes

   Failures often happen due to tight coupling and lack of fault tolerance.

2. Step 2: Identify best practice for resilience

   Loose coupling and graceful failure handling improve system stability.

3. Final Answer:

   Design services to be loosely coupled and handle failures gracefully -> Option A

4. Quick Check:

   Loose coupling = resilience [OK]

Hint: Remember: loose coupling prevents cascading failures [OK]

Common Mistakes:

• Thinking monoliths avoid failures
• Ignoring monitoring importance
• Avoiding retries completely

2. Which syntax correctly represents a retry mechanism with a limit in a microservice call?

easy

A. while(true) { callService() }

B. retry(count=-1) { callService() }

C. retry(0) { callService() }

D. retry(count=5) { callService() }

Solution

1. Step 1: Understand retry syntax with limits

   Retries must have a positive count to limit attempts.

2. Step 2: Evaluate options

   retry(count=5) { callService() } uses a positive count (5), valid retry limit; others are infinite or zero retries.

3. Final Answer:

   retry(count=5) { callService() } -> Option D

4. Quick Check:

   Positive retry count = correct syntax [OK]

Hint: Retries need a positive count to avoid infinite loops [OK]

Common Mistakes:

• Using infinite loops for retries
• Setting retry count to zero or negative
• Ignoring retry limits

3. Given this pseudocode for a microservice call with fallback:

result = callService() or fallbackService()

What will be the output if callService() fails but fallbackService() succeeds?

medium

A. An error is thrown and no result is returned

B. The result from callService() is returned despite failure

C. The result from fallbackService() is returned

D. Both results are combined and returned

Solution

1. Step 1: Understand fallback behavior

   If the main service fails, fallback is called to provide a result.

2. Step 2: Analyze given code

   Since callService() fails, fallbackService() result is used.

3. Final Answer:

   The result from fallbackService() is returned -> Option C

4. Quick Check:

   Fallback returns result on failure [OK]

Hint: Fallback runs only if main service fails [OK]

Common Mistakes:

• Assuming error is thrown without fallback
• Thinking main service result returns despite failure
• Believing results combine automatically

4. A microservice call retries 3 times on failure but never succeeds. What is the main issue in this retry design?

medium

A. No fallback mechanism to handle persistent failure

B. Retries cause infinite loops without limits

C. Retries are too few to recover from failure

D. Service calls are synchronous causing delays

Solution

1. Step 1: Analyze retry behavior

   Retries are limited to 3 attempts, so no infinite loop.

2. Step 2: Identify missing resilience feature

   Without fallback, system cannot recover after retries fail.

3. Final Answer:

   No fallback mechanism to handle persistent failure -> Option A

4. Quick Check:

   Retries need fallback for persistent failures [OK]

Hint: Retries alone can't fix persistent failures; add fallback [OK]

Common Mistakes:

• Confusing retry limits with infinite loops
• Assuming more retries always solve failures
• Ignoring fallback importance

5. You design a microservices system where Service A calls Service B, which calls Service C. Service C is unstable and often fails. Which design improves overall system stability best?

hard

A. Make Service A call Service C directly to reduce hops

B. Add retries with limits and fallback in Service B for calls to Service C

C. Remove retries to avoid extra load on Service C

D. Combine Services B and C into one to avoid network calls

Solution

1. Step 1: Identify failure point and impact

   Service C is unstable, causing failures in the chain.

2. Step 2: Apply fault tolerance best practices

   Retries with limits and fallback in Service B isolate failures and improve stability.

3. Step 3: Evaluate other options

   Direct calls or combining services increase coupling or load; removing retries loses resilience.

4. Final Answer:

   Add retries with limits and fallback in Service B for calls to Service C -> Option B

5. Quick Check:

   Retries + fallback near failure = stability [OK]

Hint: Place retries and fallback close to unstable service [OK]

Common Mistakes:

• Increasing coupling by combining services
• Bypassing intermediate services causing tight coupling
• Removing retries losing fault tolerance