Chapter 20: Retries, Hedging, and Retry Policies

Automatic Retries (Service Config)

// Service config JSON (set on channel or via name resolver):
{
  "methodConfig": [{
    "name": [{"service": "mypackage.MyService"}],
    "retryPolicy": {
      "maxAttempts": 3,
      "initialBackoff": "0.1s",
      "maxBackoff": "1s",
      "backoffMultiplier": 2,
      "retryableStatusCodes": ["UNAVAILABLE", "DEADLINE_EXCEEDED"]
    }
  }]
}

Hedging (Speculative Retries)

Send the same request to multiple backends simultaneously. Use the first response, cancel the rest. Reduces tail latency at the cost of extra load.

// Hedging policy:
{
  "hedgingPolicy": {
    "maxAttempts": 3,
    "hedgingDelay": "0.5s"  // send next attempt after 500ms if no response
  }
}

Retry vs Hedging

Aspect	Retry	Hedging
When	After failure	Before failure (speculative)
Extra load	Only on failure	Always (sends duplicates)
Latency benefit	Only avoids total failure	Reduces p99 tail latency
Requirement	Idempotent RPCs	Idempotent RPCs

⚠️ Only Retry Idempotent Operations

Retrying a non-idempotent RPC (like "create order") can cause duplicates. Only enable retries for safe-to-repeat operations, or use idempotency keys.

← Previous Next →