Support backup requests

[timothybasanov]

Not a Contribution.

As mentioned in #159 and #291 there is an additional layer on top of hedged/staggered retries that we may need to support: backup requests. In short, backup requests are similar to fallbacks, but done in-parallel.

What's the difference with hedged retries? What features are required?

• Backup requests are issued immediately and in parallel to the main request
• Backup request results are not used unless the main request and its retries fail
• We do not need to support fallbacks for a main request if a backup request is present

Ideally backup requests should support separate retry policies and circuit breakers. Both are needed for real world requests over the network. But even if retries/circuit breakers are not supported by a backup policy, a workaround would be to implement them as a separate Failsafe executor that is only used within a Fallback policy's lambda.

One of the ways to achieve this in terms of API would be to extend an existing Fallback policy to allow its execution to start in parallel to the main request.

[whiskeysierra]

Backup requests are issued immediately and in parallel to the main request

To the same target or an alternative one?

What's the difference with hedged retries?

I've seen the names backup requests and hedged requests as synonyms until now.

I've written a Backup request executor for failsafe before: https://github.com/zalando/riptide/blob/main/riptide-failsafe/src/main/java/org/zalando/riptide/failsafe/BackupRequestExecutor.java