Hedged requests
Send a second copy of a slow call and keep the first answer, so a rare slow server stops setting your tail latency.
A hedged request cuts the tail by racing a second copy of a call that is taking too long.
Use it when#
The p99 is far above the p50 because a few calls land on a slow replica or a busy moment.
The call is read-only or safe to repeat.
The callee has spare capacity for a little extra traffic.
How it works#
The caller sends a request and starts a clock. If no answer arrives by about the p95 latency, it sends the same request to another replica and uses whichever answer comes first. A call is slow only when both copies are slow, so the rare slow answer must happen twice. Google described this in "The Tail at Scale". Hedging only after the p95 means about 5% of calls get a second copy, not all of them.
What it costs#
The callee sees extra load, and a hedge at the wrong threshold doubles it. A hedge on a write can run it twice, so use it for reads or idempotent calls. It also hides a slow replica instead of fixing it, and during real overload the extra copies make things worse. Cancel the losing copy when the winner returns.
In Quorum#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | large | Large, so the Database link sets the tail. |
| Database | Instance size | medium | Has the room for a small share of extra calls. |
| Link App Server → Database | Hedge | On | The Link sends a second copy of a slow call and keeps whichever answer comes first, which shortens the tail. |
Research this Design needs: Timeouts and retries, Metrics, Percentiles, Distributed tracing, Hedged requests.
Hedge is a setting on a Link, so each Link chooses for itself. It sends a second copy after a slow first one and keeps the faster answer: the tail drops, and the Database sees a small share of extra calls. Hedged requests unlocks it and needs Tracing. The glossary defines hedged request and tail at scale.