Idiomatic Error Handling: Transient vs. Client Errors

Two Classes of Error

Robust integration code has to distinguish two fundamentally different failure classes and respond to each correctly:

The SDKs surface these as typed exceptions, so integration code can branch on error type rather than parsing raw status codes by hand.

Why Backoff (and Jitter) Specifically

A 429 or 529 means the request itself was fine -- the service is asking you to slow down or come back later. Retrying immediately (or in a tight loop) tends to make the underlying congestion worse. Exponential backoff spaces retries out with growing delay; adding jitter (small randomization) prevents many clients from retrying in lockstep and re-creating the same spike.

Why Not for 400/401

A 400 or 401 means the request itself is wrong -- a malformed payload or an invalid credential. No amount of waiting fixes a bug in the request; retrying the identical request will fail identically. These require fixing the payload or the key, not backoff.

Common exam traps

• Applying the same backoff-and-retry strategy to a 400 or 401 as to a 429/529. Retrying an unfixed bug just repeats the failure.
• Treating a 429 as a bug to fix in the payload rather than a transient, retryable condition.
• Retrying without jitter, which can cause synchronized retry storms across many clients hitting the same transient condition.