Your p50 latency is 20ms. Your p99 is 800ms. That p99 isn't a network problem or a slow query — it's the tail. One replica is doing GC, another is on a noisy neighbor VM, a third is finishing a background compaction. On any given request, most replicas are fast, but the one you happened to pick might be having a bad day.

Hedged requests attack this directly: fire the request to replica A, wait a short delay, and if you haven't heard back, fire the same request to replica B. Take whichever response arrives first, cancel the other.

Google's The Tail at Scale paper reports that a 5% hedge (send the backup after the p95 latency) can cut p99 latency by 40x while adding only ~5% extra load. That's the trade: a small, tunable amount of duplicate work in exchange for dramatically tighter tail behavior.

Concrete example. A recommendation service reads user embeddings from a 3-replica key-value store. p50 is 8ms, p99 is 250ms. Without hedging, a page that fans out to 20 embedding lookups has a ~18% chance at least one lookup hits p99 (1 − 0.99^20). With hedging fired at 15ms (the p90), that probability collapses because you'd need both the primary and backup replica to be slow — a squared probability. Extra RPC volume: about 10%.

Rule of thumb. Fire the hedge at your current p95. That guarantees hedging adds ~5% extra load in steady state (only the slowest 5% of requests spawn a duplicate), while catching every request that's about to become a tail event.

Where it works:

• Idempotent reads — safe to duplicate, easy to cancel.
• Multi-replica stores — you have somewhere else to send the retry.
• Independent failure modes — GC on one node doesn't mean GC on another. Correlated failures (a bad deploy hitting all replicas) neutralize hedging.

Where it hurts:

• Writes — unless the backend is idempotent, you'll double-apply.
• Overloaded systems — hedging adds load right when the system is struggling. Under saturation it makes tails worse. Combine with an adaptive circuit: disable hedging when queue depth exceeds a threshold.
• Uncancellable work — if the "loser" keeps running server-side, you paid for both.

Production implementations (gRPC, Envoy, DynamoDB SDK) all support hedging as a first-class knob. Turn it on for read paths, tie the delay to your live p95 percentile, and put a kill switch on it for overload scenarios.