Graceful degradation in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Graceful Degradation in Microservices

Which of the following best describes the concept of graceful degradation in a microservices architecture?

A The system shuts down completely to avoid inconsistent states when any service fails.

B The system continues to operate with reduced functionality when some services fail.

C The system automatically scales up all services to prevent any failure.

D The system ignores failures and retries indefinitely without fallback.

💡 Hint

Think about how a system behaves when parts of it stop working but the whole does not fail.

Graceful degradation means the system keeps working with limited features instead of failing completely.

❓ Architecture

intermediate

Designing a Graceful Degradation Strategy

You are designing a microservices system for an online store. Which architectural approach best supports graceful degradation when the payment service is down?

A Allow users to place orders but queue payments for later processing.

B Block all order placements until the payment service is fully operational.

C Automatically cancel all orders if payment service is unavailable.

D Redirect users to a static error page without any order options.

💡 Hint

Consider how to keep the core functionality available even if payment is temporarily unavailable.

Queuing payments allows the system to accept orders and process payments later, maintaining user experience despite partial failure.

❓ scaling

advanced

Scaling Considerations for Graceful Degradation

In a microservices system, which scaling strategy best supports graceful degradation during high load on a critical service?

A Ignore load and let the service fail to force a restart.

B Increase the number of requests sent to the overloaded service to speed up processing.

C Disable all other services to focus resources on the overloaded service.

D Implement circuit breakers to temporarily stop requests to the overloaded service and fallback to cached data.

💡 Hint

Think about how to protect a service under stress while still providing some response.

Circuit breakers prevent cascading failures by stopping calls to failing services and providing fallback responses, enabling graceful degradation.

❓ tradeoff

advanced

Trade-offs in Graceful Degradation Design

What is a common trade-off when implementing graceful degradation in microservices?

A Reduced feature availability in exchange for higher system availability.

B Increased feature complexity with no impact on system availability.

C Complete system shutdown to ensure data consistency.

D Unlimited retries causing increased latency but no feature loss.

💡 Hint

Consider what the system sacrifices to keep running during partial failures.

Graceful degradation often means some features are limited or disabled to keep the system running smoothly.

❓ estimation

expert

Estimating Impact of Graceful Degradation on User Experience

A microservices system has 10 services. If 2 services degrade gracefully by reducing functionality, what percentage of total services are fully operational?

A 60%

B 20%

C 80%

D 100%

💡 Hint

Calculate the number of services fully operational versus total services.

If 2 out of 10 services degrade, 8 remain fully operational, which is 80%.

Practice

1. What is the main goal of graceful degradation in microservices?

easy

A. To increase the number of microservices for better scaling

B. To immediately stop all services when one fails

C. To keep the system running with reduced functionality during failures

D. To replace microservices with a monolithic architecture

Solution

1. Step 1: Understand the concept of graceful degradation

   Graceful degradation means the system continues to work even if some parts fail, but with limited features.

2. Step 2: Identify the goal in microservices context

   In microservices, it ensures users still get responses, possibly simpler or fallback, instead of total failure.

3. Final Answer:

   To keep the system running with reduced functionality during failures -> Option C

4. Quick Check:

   Graceful degradation = reduced functionality during failure [OK]

Hint: Graceful degradation means partial working, not full stop [OK]

Common Mistakes:

• Thinking graceful degradation means full system shutdown
• Confusing graceful degradation with scaling techniques
• Assuming it replaces microservices with monolith

2. Which of the following is a correct way to implement graceful degradation in a microservice call?

easy

A. Restart the entire microservice cluster immediately

B. Return an error and stop the entire request flow

C. Ignore the failure and return no response

D. Use a fallback response when the called service is unavailable

Solution

1. Step 1: Identify how graceful degradation handles failures

   It uses fallback responses or simpler data to keep the system responsive.

2. Step 2: Match the option that uses fallback

   Use a fallback response when the called service is unavailable describes using fallback response when a service is down, which is correct.

3. Final Answer:

   Use a fallback response when the called service is unavailable -> Option D

4. Quick Check:

   Fallback response = graceful degradation [OK]

Hint: Fallback response is key to graceful degradation [OK]

Common Mistakes:

• Stopping entire request instead of fallback
• Ignoring failure without response
• Restarting cluster is not graceful degradation

3. Consider this pseudocode for a microservice call with graceful degradation:

response = callService()
if response == null:
    response = getCachedData()
return response

What will be returned if callService() fails?

medium

A. Cached data as fallback

B. Null value

C. An error message

D. Empty string

Solution

1. Step 1: Analyze the code flow when callService() fails

   If callService() returns null (failure), the code fetches cached data as fallback.

2. Step 2: Determine the returned value

   The fallback cached data is returned instead of null or error.

3. Final Answer:

   Cached data as fallback -> Option A

4. Quick Check:

   Fallback cached data returned on failure [OK]

Hint: Null response triggers fallback to cached data [OK]

Common Mistakes:

• Assuming error message is returned
• Thinking null is returned directly
• Confusing empty string with fallback data

4. A microservice uses this code snippet for graceful degradation:

try {
  data = fetchFromService()
} catch (Exception e) {
  data = null
}
return data.toString()

What is the main problem with this code?

medium

A. It does not handle exceptions properly

B. It returns null.toString() causing a runtime error

C. It always returns an empty string

D. It retries the service call infinitely

Solution

1. Step 1: Understand exception handling and return statement

   If fetchFromService() fails, data is set to null, then data.toString() is called.

2. Step 2: Identify the error caused by calling toString() on null

   Calling toString() on null causes a runtime NullPointerException or similar error.

3. Final Answer:

   It returns null.toString() causing a runtime error -> Option B

4. Quick Check:

   Calling toString() on null causes error [OK]

Hint: Calling method on null causes runtime error [OK]

Common Mistakes:

• Ignoring null check before toString()
• Assuming exception is handled fully
• Thinking it retries infinitely

5. You design a microservice system where the payment service may fail. To apply graceful degradation, which approach is best?

hard

A. Return a simplified confirmation without payment details and log failure for retry

B. Block the entire order process until payment service recovers

C. Send an error response to the user immediately without fallback

D. Remove the payment service and process orders without payment

Solution

1. Step 1: Understand graceful degradation for critical service failure

   When payment service fails, system should still respond with limited info, not block or error out.

2. Step 2: Evaluate options for best graceful degradation

   Return a simplified confirmation without payment details and log failure for retry returns simplified confirmation and logs failure for retry, maintaining user experience and system reliability.

3. Final Answer:

   Return a simplified confirmation without payment details and log failure for retry -> Option A

4. Quick Check:

   Simplified response + retry = graceful degradation [OK]

Hint: Simplify response and log failure for retry [OK]

Common Mistakes:

• Blocking entire process on failure
• Sending immediate error without fallback
• Removing critical service entirely