Retries and Idempotency

Retry policies in service config

gRPC clients support retry policies configured through the service config: maximum attempts, exponential backoff and which status codes to retry (typically UNAVAILABLE). Only retry operations that are idempotent or protected by idempotency keys; a retried non-idempotent PlaceOrder could create two orders. Hedging sends extra copies of slow idempotent calls. Combine retries with deadlines and limits so retries do not amplify an outage.

A retry policy in service config

JSON service config (supported by several gRPC implementations).

{
  "methodConfig": [{
    "name": [{ "service": "shop.v1.OrderService", "method": "GetOrder" }],
    "timeout": "2s",
    "retryPolicy": {
      "maxAttempts": 4,
      "initialBackoff": "0.1s",
      "maxBackoff": "1s",
      "backoffMultiplier": 2,
      "retryableStatusCodes": ["UNAVAILABLE"]
    }
  }]
}

Add request IDs to mutating RPCs

An idempotency key in the request lets the server detect and safely ignore retried duplicates.

Quick check: Why is retrying PlaceOrder blindly dangerous?

• It is not idempotent and could create duplicate orders
• gRPC forbids retries
• Retries always time out
• It changes the proto file