Lessons from microservices failures - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a common cause of microservices failures related to service dependencies?

Tight coupling between services causes failures to cascade when one service goes down.

beginner

Why is proper monitoring important in microservices architectures?

Monitoring helps detect failures early and understand system health to prevent outages.

intermediate

What lesson can be learned about data management from microservices failures?

Avoid sharing databases directly between services to prevent data corruption and tight coupling.

intermediate

How does network latency affect microservices reliability?

High latency can cause timeouts and failures; designing for retries and timeouts is essential.

advanced

What is the importance of designing for failure in microservices?

Systems should expect failures and handle them gracefully to maintain availability and user experience.

What is a key reason microservices fail due to tight coupling?

A One service failure causes others to fail

B Services run on the same server

C Services use different programming languages

D Services have separate databases

Tight coupling means services depend heavily on each other, so one failure cascades.

Which practice helps prevent cascading failures in microservices?

A Using circuit breakers

B Sharing a single database

C Ignoring timeouts

D Hardcoding service URLs

Circuit breakers stop calls to failing services to prevent cascading failures.

Why should microservices avoid sharing databases directly?

A It simplifies deployment

B It improves performance

C It causes data corruption and tight coupling

D It reduces network traffic

Sharing databases tightly couples services and risks data integrity.

What role does monitoring play in microservices?

A Eliminate the need for retries

B Increase network latency

C Replace logging

D Detect failures early and understand system health

Monitoring provides visibility to detect and respond to issues quickly.

Designing for failure means:

A Avoiding failures by not using microservices

B Expecting failures and handling them gracefully

C Restarting services manually

D Ignoring errors to improve speed

Systems should be resilient by anticipating and managing failures.

Explain the main lessons learned from microservices failures related to service dependencies and data management.

Think about how services depend on each other and share data.

Describe how monitoring and designing for failure improve microservices reliability.

Consider how to keep the system healthy and responsive despite failures.

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