Scalability
Retry
Automatically re-attempting a failed operation to ride out transient glitches — a dropped packet, a brief timeout, a momentary 503. It is simple and effective for idempotent calls. Done naively it is dangerous: retrying non-idempotent writes duplicates them, and synchronised retries create thundering-herd storms that make an outage worse.
Purpose
A retry re-attempts a failed operation on the bet that the failure was transient — a dropped packet, a momentary 503, a brief lock. For distributed systems where such glitches are constant background noise, retries convert them from user-visible errors into invisible hiccups.
When to Use It
Idempotent reads and writes over the network: fetching a resource, PUTting a state, polling a queue. Every HTTP client, message consumer and cloud SDK either retries for you or expects you to configure it.
Trade-offs
Two sharp edges. Retrying a non-idempotent operation that actually succeeded duplicates it — the double-charged card. And synchronized retries amplify outages: a struggling service receives its normal load multiplied by every client's retry storm, precisely when it can least afford it. Retries without backoff and limits are an attack on yourself.
Implementation
Retry only errors worth retrying (timeouts, 429, 5xx — never 400s), cap attempts (2–3 is usually right), and always pair with exponential backoff plus jitter. Make the operation idempotent first — idempotency keys for writes — and respect Retry-After headers. Consider a retry budget so retries can never exceed a fraction of live traffic.