Lessons from microservices failures - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is a common cause of cascading failures in microservices?

In a microservices architecture, what often triggers cascading failures that affect multiple services?

A Deploying services with different programming languages

B Using too many databases for different services

C A single service becoming overloaded and causing dependent services to fail

D Having too many developers working on the same service

💡 Hint

Think about how one service's failure can impact others that rely on it.

Cascading failures happen when one overloaded or failing service causes its dependent services to also fail, spreading the problem.

❓ Architecture

intermediate

Which design helps prevent cascading failures in microservices?

Which architectural pattern is best suited to isolate failures and prevent cascading effects in microservices?

A Circuit breaker pattern that stops calls to failing services

B Direct synchronous calls without retries

C Using a single database for all services

D Monolithic deployment of all services together

💡 Hint

Think about a way to stop repeated calls to a failing service.

The circuit breaker pattern detects failures and stops calls to a failing service temporarily, preventing cascading failures.

❓ scaling

advanced

What is a key challenge when scaling microservices to avoid failures?

When scaling microservices, what is a critical challenge that can lead to failures if not handled properly?

A Ensuring consistent data across distributed services

B Using the same hardware for all services

C Avoiding any form of caching

D Deploying all services in a single data center

💡 Hint

Think about data consistency when services are spread out.

Maintaining consistent data across distributed services is difficult but essential to avoid failures and data corruption.

❓ tradeoff

advanced

What is a tradeoff when using asynchronous communication in microservices?

Choosing asynchronous communication between microservices improves resilience but introduces what tradeoff?

A Higher latency in synchronous calls

B Simpler debugging and tracing

C Reduced fault tolerance

D Increased complexity in handling eventual consistency

💡 Hint

Think about data state when messages are delayed.

Asynchronous communication can cause data to be temporarily inconsistent, requiring careful handling of eventual consistency.

❓ estimation

expert

Estimate the maximum number of microservices calls per second before failure risk increases

A microservices system has 50 services, each making 10 calls per second to others. What is the approximate total number of calls per second in the system, and why does exceeding this number increase failure risk?

A 50 calls per second; exceeding this causes database locks

B 500 calls per second; exceeding this overloads network and services causing failures

C 1000 calls per second; exceeding this causes CPU overheating

D 100 calls per second; exceeding this causes memory leaks

💡 Hint

Multiply services by calls per service to find total calls.

50 services × 10 calls each = 500 calls per second. Going beyond this can overload network and services, increasing failure risk.

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