A nightly load calls a vendor's API, which is unavailable during the vendor's occasional maintenance windows and returns HTTP 503 errors. When that happens the job fails on the first error, and nobody notices until analysts find stale data the next morning. Which improvement should the DBA make?
Select an answer to reveal the explanation.
Short Explanation
Sources go down; that's life. The grown-up pipeline waits a bit, tries again, waits a little longer, and if it still can't get through, it taps you on the shoulder with an alert. What you never want is a job that fails quietly, or worse, one that pretends everything went fine.
Full Explanation
Data unavailability is a normal condition in integration work: sources have maintenance windows, outages and rate limits. HTTP 503 Service Unavailable signals a temporary condition, so the appropriate response is to retry after a delay rather than fail immediately. Exponential backoff increases the wait between attempts, giving the source time to recover without flooding it with requests. If the source is still unavailable after a defined number of attempts or a time budget, the job should fail clearly and alert the on-call team so the delay is handled before users rely on stale data. Removing error handling so the job always reports success is the opposite of what is needed; it hides failures and lets stale or incomplete data appear current. Enlarging the database connection pool addresses contention for database connections, but the failure is on the vendor's API side, so more database connections change nothing. Rerunning every five minutes and overwriting the target with whatever comes back could replace good data with empty or partial results during an outage and puts unnecessary load on the vendor. Exam caveat: retries should be limited and idempotent so that a successful retry does not duplicate rows. Operational check: simulate a 503 in a test environment, confirm the job retries with growing delays, and confirm an alert fires when the final attempt fails.