Retries

Retries recover from transient failures — network blips, 503s, leader election — but retry only when safe and bounded. Non-idempotent operations without keys must not blind retry. Cap attempts, respect Retry-After, and distinguish retriable from permanent errors.

Trade-off: improved success rate versus amplified load during incidents (retry storms).

On interviews: list retriable HTTP status codes; explain why retrying a timeout without idempotency is dangerous.

Common pitfalls: infinite retries; retrying 400-class errors; all clients retrying in sync after recovery.

Checklist:

• Retry transient errors with max attempts.
• Require idempotency for mutating retries.
• Exponential backoff with jitter.
• Alert on retry ratio spikes.