การนำกลไกสำรองและการหมดเวลาการรอไปใช้

In this lesson, we'll dive into two crucial patterns for building resilient microservices: Fallbacks and Timeouts.

These patterns help your applications gracefully handle failures and slow responses from other services, making your system more robust and reliable.

A fallback mechanism provides an alternative course of action when a primary operation fails or encounters an error.

• It ensures your application can still respond, even if partially, instead of completely failing.
• Think of it as a plan B for your service calls.
• This leads to graceful degradation, where the system provides reduced functionality rather than total failure.

Imagine an e-commerce site. If the service providing personalized product recommendations fails, you wouldn't want the entire page to break.

A fallback could display:

• Popular items (default list)
• Cached recommendations
• A simple message like 'Recommendations currently unavailable'

The user experience remains intact, even with a minor issue.

Let's see a basic Java example. Here, if our 'external service' throws an error, we catch it and return a default value instead of letting the application crash.

While fallbacks handle failures, timeouts address slow responses. A service might not fail outright, but it could take too long to respond.

• Resource Exhaustion: Waiting indefinitely ties up resources (threads, connections).
• Cascading Failures: A slow service can make other dependent services slow, leading to a system-wide slowdown.

Timeouts set a maximum duration for an operation.

When making network calls, you'll often encounter different types of timeouts:

• Connection Timeout: The maximum time allowed to establish a connection to the remote service. If no connection is made within this time, it fails.
• Read Timeout: The maximum time allowed for data to be received after the connection is established. If the service stops sending data, this timeout triggers.
• Request Timeout: An overall timeout for the entire operation, from start to finish. This often encompasses both connection and read timeouts.

In Java, setting timeouts depends on the client library you're using (e.g., OkHttp, HttpClient). Conceptually, it looks like this:

This ensures your request won't hang forever.

Timeouts and fallbacks are powerful when used together. A timeout triggers a failure, which can then be handled by a fallback.

Let's extend our previous example. We'll simulate a slow service call. If it takes too long, a timeout will occur, and our fallback will provide a default response.

By combining timeouts and fallbacks, you achieve a higher level of resilience:

• Improved User Experience: Users don't wait indefinitely for a page to load or an operation to complete.
• Resource Protection: Your services don't exhaust resources waiting for unresponsive dependencies.
• System Stability: Prevents cascading failures, where one slow service brings down many others.
• Predictable Behavior: Your system behaves predictably even under stress.

You are designing a microservice that calls an external payment gateway. If the gateway is slow or unavailable, you want to:

• Prevent your service from hanging indefinitely.
• Show a 'Payment currently unavailable' message to the user instead of an error page.

Which resilience patterns should you prioritize for this scenario?

Great job! You've learned about two essential resilience patterns:

• Fallbacks: Provide alternative responses to gracefully handle failures, ensuring a better user experience.
• Timeouts: Set limits on how long an operation can take, preventing resource exhaustion and cascading failures from slow services.

Using these patterns together makes your microservices more robust and reliable.