Стратегии повторных попыток для Саг

When a saga executes, its individual steps often involve calling other microservices. These calls can sometimes fail due to temporary issues like network glitches, service restarts, or brief overloads.

Retry strategies are essential mechanisms that allow saga steps to automatically re-attempt failed operations, helping the overall saga complete successfully despite transient errors.

A simple retry mechanism might just wait a fixed, short period (e.g., 1 second) and then re-attempt the operation. While better than nothing, this approach has limitations:

• It can quickly overwhelm a service that is already struggling.
• If many services retry at the same fixed interval, it can create a 'retry storm'.
• It doesn't adapt to the severity or duration of the failure.

Exponential backoff is a smarter retry strategy. Instead of a fixed delay, it progressively increases the waiting time between successive retries. This gives a failing service more time to recover before being hit again.

• Start with a small initial delay (e.g., 100ms).
• Double or multiply the delay for each subsequent retry (200ms, 400ms, 800ms...).
• This strategy significantly reduces the load on a recovering service.

Let's look at a simple Java example of how exponential backoff increases the delay between retry attempts:

Even with exponential backoff, if many services start failing and retrying at the same time, their delays might still synchronize. This can lead to a 'thundering herd' problem where they all retry simultaneously.

Adding jitter (a small, random amount of time) to the calculated backoff delay helps prevent this. It randomizes the exact retry times, spreading out the requests and reducing peak load.

While retries handle transient failures, sometimes a service is truly down or critically impaired. Continuously retrying such a service is wasteful and can worsen the problem.

This is where circuit breakers come in. A circuit breaker wraps an operation and, if it fails too many times, 'opens the circuit' to prevent further calls to the failing service. This protects the calling service from waiting on a dead resource and gives the failing service time to recover without being hammered by retries.

The states of a circuit breaker directly impact retry behavior:

• Closed: Operations are allowed. If failures occur, retries (with backoff/jitter) are attempted normally.
• Open: The circuit breaker immediately fails any request without attempting the operation. This means no retries are made, saving resources and failing fast.
• Half-Open: A limited number of requests are allowed through to test if the service has recovered. If these 'test' requests succeed, the circuit closes; if they fail, it re-opens. Retries can be applied to these test requests.

Effective retry strategies are often configurable. Key parameters you can customize include:

• Maximum Retries: The absolute limit of how many times an operation should be re-attempted.
• Maximum Delay: An upper bound for the backoff delay to prevent excessively long waits.
• Timeout: How long to wait for a single attempt of an operation to complete before considering it a failure.
• Retryable Exceptions: Defining which types of errors (e.g., network errors vs. business logic errors) should trigger a retry.

When implementing retries, it's crucial that the operations being retried are idempotent. An operation is idempotent if executing it multiple times has the same effect as executing it once.

For example, if a 'charge credit card' operation is retried, but the original request actually went through, an idempotent design prevents the customer from being charged twice. This is a vital concept for reliable distributed transactions.

In this lesson, we explored crucial retry strategies for robust saga execution. We learned about:

• The importance of retries for transient failures in saga steps.
• How exponential backoff intelligently increases retry delays.
• Adding jitter to prevent synchronized retry storms and the 'thundering herd' problem.
• The role of circuit breakers in preventing retries to persistently failing services.
• Configurable retry policies and the critical need for idempotent operations.

These techniques are vital for building resilient microservices that can recover from temporary issues and maintain high availability.