12.5 · Retries, backoff, idempotency and cancellation
Networks fail constantly and in different ways. A client that retries well hides most of it; one that retries badly turns a blip into an outage.
Mental model. Retry only what is safe to repeat, only when failure is probably temporary, and always with waiting that grows and spreads out.
Retrying safely
Idempotency, backoff with jitter, and cancellation.
- How should a client retry failed requests: what to retry, how long to wait, and what idempotency has to do with it?
Three questions decide a retry. Is the failure transient? Retry timeouts, connection resets, DNS or connectivity errors that come back (URLError codes like…
More in Networking
- 12.1 · Sessions, configurations, tasks, delegates and background transfers
- 12.2 · HTTP versions, TLS, App Transport Security and certificate pinning
- 12.3 · Pagination, caching and conditional requests, and authentication refresh
- 12.4 · WebSockets, multipart and large transfers, and network path monitoring
- 12.6 · REST, GraphQL and gRPC, and building a client platform
- 12.7 · Image loading pipelines: download, decode, downsample, cache
- 12.8 · Building URLs, reading headers, classifying errors and timeouts
- 12.9 · Single-flight token refresh, streaming lines, multipart bodies and request signing
- 12.10 · Network.framework, background sessions, delegates versus async, diagnosing and measuring