A Python permit service calling a third-party address validator fails the whole submit when the vendor blips for two seconds. Which resilience approach should developers apply in application code?
Select an answer to reveal the explanation.
Short Explanation
A two-second hiccup from the address vendor should not trash the whole permit like a blown fuse. Put a timeout on the call, retry with backoff, and degrade gracefully if it is still down. That is resilient application code.
Full Explanation
A Python permit service that fails the entire submit when a third-party address validator blips for two seconds needs application-level resilience: timeouts, retries with exponential backoff, and graceful degradation so a vendor blip does not void the whole permit. Timeouts bound thread and Lambda occupancy; backoff with jitter avoids stampedes when the vendor recovers; degradation might accept the address as “unvalidated—manual review” or queue enrichment while still persisting the citizen’s application. Municipal permitting cannot treat every dependency as perfectly available.
Removing timeouts so the thread waits indefinitely ties up capacity and worsens cascading failure. Failing the entire submit on the first network error with no retry turns transient faults into citizen rework. A single immediate retry with no backoff then always surfacing 500 still lacks patience for brief blips and offers no degraded path when the vendor remains down.
Exam caveat: retries are for transient faults (timeouts, 429, 503), not for permanent 400 validation errors. Idempotent validator calls matter if retries can duplicate side effects. Circuit breakers complement retries when outages persist.
Operational check: set explicit client timeouts; retry transient errors with exponential backoff and jitter; define a degraded permit state when validation is unavailable; log correlation IDs for vendor calls; and alert on elevated validator failure rates so clerks know manual review volume will spike.