Why advanced patterns solve edge cases in Microservices - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a microservice that handles user requests asynchronously.

Microservices

def handle_request(request):
    # Process request asynchronously using [1]
    pass

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

Asynchronous_api

Bdirect_call

Cblocking_io

Dmessage_queue

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing synchronous methods that block the service.

Using a message queue allows asynchronous processing, which helps handle requests without blocking.

2fill in blank

medium

Complete the code to implement a retry mechanism for failed microservice calls.

Microservices

def call_service():
    for attempt in range(3):
        response = send_request()
        if response.status == [1]:
            return response
    return None

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

A200

B301

C404

D500

Attempts:

3 left

💡 Hint

Common Mistakes

Retrying on success status instead of failure.

The retry should continue until a 200 OK status is received, indicating success.

3fill in blank

hard

Fix the error in the circuit breaker pattern implementation by completing the condition.

Microservices

if failure_count > [1]:
    open_circuit()

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

Aretry_limit

Btimeout

Cthreshold

Dsuccess_count

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated variables like timeout or success_count.

The circuit breaker opens when the failure count exceeds a defined threshold.

4fill in blank

hard

Fill both blanks to implement a fallback method when the primary service fails.

Microservices

try:
    result = primary_service.call()
except [1]:
    result = [2]()

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

AServiceUnavailableError

Bfallback_service.call

CTimeoutError

Dretry_service.call

Attempts:

3 left

💡 Hint

Common Mistakes

Catching wrong exceptions or calling retry instead of fallback.

When the ServiceUnavailableError occurs, the system calls the fallback_service.call() method.

5fill in blank

hard

Fill all three blanks to implement a load balancer that distributes requests evenly.

Microservices

class LoadBalancer:
    def __init__(self, servers):
        self.servers = servers
        self.index = 0

    def get_server(self):
        server = self.servers[[1]]
        self.index = (self.index + [2]) % [3]
        return server

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

Aself.index

B1

Clen(self.servers)

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using fixed indexes or wrong modulo values.

The load balancer returns the server at self.index, then increments the index by 1 modulo the number of servers (len(self.servers)) to cycle through servers evenly.

Practice

1. Why do advanced microservice design patterns help solve edge cases better than simple designs?

easy

A. They rely only on synchronous calls to ensure order.

B. They reduce the number of microservices to simplify the system.

C. They remove all network communication to avoid latency.

D. They add mechanisms to handle failures and complex interactions reliably.

Solution

1. Step 1: Understand simple design limitations

   Simple microservices often miss handling failures and complex service interactions, leading to errors in edge cases.

2. Step 2: Role of advanced patterns

   Advanced patterns add retries, circuit breakers, event-driven flows, and state management to improve reliability and handle tricky cases.

3. Final Answer:

   They add mechanisms to handle failures and complex interactions reliably. -> Option D

4. Quick Check:

   Advanced patterns = handle failures reliably [OK]

Hint: Advanced patterns add fault tolerance and reliability [OK]

Common Mistakes:

• Thinking advanced patterns reduce microservices count
• Assuming no network communication is possible
• Believing synchronous calls alone solve edge cases

2. Which of the following is a correct syntax for implementing a circuit breaker pattern in microservices?

easy

A. Wrap service calls with a circuit breaker that opens after failures.

B. Call services directly without any error handling.

C. Use a retry loop without tracking failures.

D. Use synchronous calls only to avoid failures.

Solution

1. Step 1: Identify circuit breaker purpose

   Circuit breaker stops calls to failing services after threshold to prevent cascading failures.

2. Step 2: Correct syntax usage

   Wrapping calls with a circuit breaker that opens after failures matches the pattern's intent.

3. Final Answer:

   Wrap service calls with a circuit breaker that opens after failures. -> Option A

4. Quick Check:

   Circuit breaker = wrap calls with failure tracking [OK]

Hint: Circuit breaker wraps calls and tracks failures [OK]

Common Mistakes:

• Ignoring failure tracking in retries
• Calling services without error handling
• Assuming synchronous calls prevent failures

3. Consider this simplified pseudocode for a microservice using a retry pattern:

attempts = 0
max_attempts = 3
while attempts < max_attempts:
    response = call_service()
    if response == 'success':
        return 'done'
    attempts += 1
return 'failed'

What will be the output if the service fails twice then succeeds on the third call?

medium

A. "done"

B. "failed"

C. "success"

D. "error"

Solution

1. Step 1: Trace retry attempts

   First two calls fail, attempts increment to 2. Third call succeeds, returns 'done'.

2. Step 2: Understand loop exit

   Loop exits early on success, so 'done' is returned before max_attempts reached.

3. Final Answer:

   "done" -> Option A

4. Quick Check:

   Retries until success = "done" [OK]

Hint: Success before max attempts returns 'done' [OK]

Common Mistakes:

• Assuming all retries fail and return 'failed'
• Confusing 'success' string with return value
• Ignoring early loop exit on success

4. A microservice uses an event-driven pattern but sometimes events are processed twice causing duplicate actions. What is the best fix?

medium

A. Remove event retries to avoid duplicates.

B. Add idempotency keys to events and check before processing.

C. Switch to synchronous calls only.

D. Ignore duplicates as they are harmless.

Solution

1. Step 1: Identify cause of duplicates

   Retries or network issues can cause events to be delivered multiple times.

2. Step 2: Apply idempotency

   Using unique keys lets the service detect and ignore duplicate events, preventing repeated actions.

3. Final Answer:

   Add idempotency keys to events and check before processing. -> Option B

4. Quick Check:

   Idempotency keys prevent duplicate processing [OK]

Hint: Use idempotency keys to avoid duplicate event effects [OK]

Common Mistakes:

• Removing retries loses fault tolerance
• Switching to sync calls ignores async benefits
• Ignoring duplicates causes inconsistent state

5. You design a microservice system where services must remain available even if dependent services fail intermittently. Which advanced pattern combination best handles this edge case?

hard

A. Synchronous calls with no retries to avoid delays.

B. Single monolithic service to avoid network failures.

C. Circuit breaker with fallback responses and event-driven retries.

D. No error handling to keep code simple.

Solution

1. Step 1: Understand availability needs

   Services must stay responsive despite failures in dependencies.

2. Step 2: Combine patterns for resilience

   Circuit breakers stop calls to failing services, fallback responses provide defaults, and event-driven retries handle eventual success.

3. Final Answer:

   Circuit breaker with fallback responses and event-driven retries. -> Option C

4. Quick Check:

   Combine circuit breaker + fallback + retries for availability [OK]

Hint: Combine circuit breaker, fallback, and retries for resilience [OK]

Common Mistakes:

• Using synchronous calls blocks availability
• Monolith avoids network but loses scalability
• No error handling causes system crashes