A courts calendar sync calls a vendor API that returns intermittent HTTP 503s. Naive immediate retries stampede the vendor. What retry strategy should application code implement?
Select an answer to reveal the explanation.
Short Explanation
Hammering a sick vendor with instant retries is like honking in a traffic jam — it makes the jam worse. Back off longer each try, preferably with jitter. Transient 503s deserve patience, not a stampede.
Full Explanation
A courts calendar sync calling a vendor API that returns intermittent HTTP 503s should implement exponential backoff, ideally with jitter, so retry spacing grows after transient errors. Immediate retries amplify load on an already struggling vendor and can trigger tighter rate limits—exactly the stampede municipal integrations must avoid. Backoff gives the vendor room to recover while still healing brief blips that would otherwise fail clerk-facing sync jobs.
Retrying as fast as the CPU allows with zero delay maximizes stampede harm. Retrying once immediately then disabling the feature for thirty days abandons availability for an outage that may last minutes. Treating every 503 as permanent failure never retries away true transients and causes unnecessary help-desk tickets.
Exam caveat: backoff applies to transient statuses; do not blindly retry 400-level client errors. Cap max attempts and route exhausted work to a DLQ. Jitter randomizes intervals so many workers do not align their retries.
Operational check: classify 503/429/timeouts as retryable; apply exponential backoff with jitter and a max attempt budget; log attempt counts with case IDs; and alert when sync lag exceeds the courts’ SLA.