Hedge against slow or failed datastore requests

[jzelinskie]

In the case of bad network performance, cache misses, or a variety of invalid assumptions that could cause latency, the distributed dispatcher should also dispatch to another instance as a "hedged bet" to guarantee a response with the least amount of latency as possible.

[jzelinskie]

Here's an excerpt from the Zanzibar paper:

Zanzibar’s distributed processing requires measures to accommodate slow tasks. For calls to Spanner and to the Leopard index we rely on request hedging (i.e. we send the same request to multiple servers, use whichever response comes back first, and cancel the other requests). To reduce round-trip times, we try to place at least two replicas of these backend services in every geographical region where we have Zanzibar servers. To avoid unnecessarily multiplying load, we first send one request and defer sending hedged requests until the initial request is known to be slow.
To determine the appropriate hedging delay threshold, each server maintains a delay estimator that dynamically computes an Nth percentile latency based on recent measurements. This mechanism allows us to limit the additional traffic incurred by hedging to a small fraction of total traffic.
Effective hedging requires the requests to have similar costs. In the case of Zanzibar’s authorization checks, some checks are inherently more time-consuming than others because they require more work. Hedging check requests would result in duplicating the most expensive workloads and, ironically, worsening latency. Therefore we do not hedge requests between Zanzibar servers, but rely on the previously discussed sharding among multiple replicas and on monitoring mechanisms to detect and avoid slow servers

[jakedt]

Changed the title, the paper has this to say explicitly about hedging redisaptch:

In the case of Zanzibar’s authorization checks, some checks are inherently more time-consuming than others be- cause they require more work. Hedging check requests would result in duplicating the most expensive workloads and, ironically, worsening latency. Therefore we do not hedge requests between Zanzibar servers, but rely on the pre- viously discussed sharding among multiple replicas and on monitoring mechanisms to detect and avoid slow servers.