# Retries and Idempotency — gRPC

Source: https://www.skillbyai.com/en/grpc/r-retries

> Recover from transient failures.

## 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).

```json
{
  "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.

**Quiz:** Why is retrying PlaceOrder blindly dangerous?

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

*Answer:* It is not idempotent and could create duplicate orders. Retry only idempotent or deduplicated operations.