2 min lesson

Rate limits, backoff, idempotency and retries

Rebuild the sequence in "Rate limits, backoff, idempotency and retries" from memory, ending with the check that proves the outcome.

Rate limits, backoff, idempotency and retriesthe four words that make plumbing production-grade

Third-party APIs throttle you, fail intermittently and occasionally double-process. Production code expects all three. Idempotency means repeating a request has the same effect as sending it once, and it is the habit candidates miss most: it prevents charging a lead twice or creating duplicate CRM records.

retry with exponential backoff, honoring 429s and using an idempotency keyts

POST /v1/contacts
Idempotency-Key: lead-7f3a9c-2026-06-15   # same key => server dedupes the create

# client retry loop (pseudocode)
for attempt in 1..5:
    res = send(request)
    if res.status == 429 or res.status >= 500:
        wait(min(2 ** attempt, 30) + jitter)   # exponential backoff + jitter
        continue
    break   # success or a 4xx we should not retry

THE SAFE RETRY LOOP

1/5

Send request: Every attempt for the same logical operation carries the same key, so the server can recognize a retry and return the original result instead of creating a second record.

diagram: flow

The four terms in one loop: respect the rate limit, back off with jitter, reuse one idempotency key and retry only the retryable.

Learn more

Full explanation

Schema drift and defensive parsing

Schema drift and defensive parsingthird-party responses change without telling you

A provider can rename a field, return null where you expected a string or version their API on you. Code that assumes a perfect response breaks silently in the night. Defensive parsing, which means validating the shape, defaulting the missing and logging the unexpected, keeps a surprise from poisoning your data.

Learn more

Full explanation

Logging and observability

Logging and observabilityso the integration is debuggable at 2am

An integration you cannot observe is one you cannot trust. Log enough to answer "did it run, did it succeed and if not, why" without redeploying. The bar is being able to debug a failed sync from logs and a dashboard instead of guessing.

Minimum viable observability

Structured logs: Request id, status, latency, error: queryable, not free-text.
Failure alerts: Page or Slack when error rate or queue depth crosses a threshold.
A dead-letter path: Events that fail repeatedly land somewhere replayable, not lost.
A health dashboard: Success rate and volume over time, so drift is visible before users feel it.

If you can't answer "did it run and why did it fail" from logs, it isn't production-ready.

Interview move

When you sketch any integration in the technical screen, narrate the failure modes unprompted: "This call gets rate-limited, so backoff; it can double-fire, so an idempotency key; the schema can drift, so defensive parsing; and I log every call so I can debug it." Naming the failure modes before you are asked is how a panel tells plumbing from a demo.

QYour integration creates a CRM contact via POST. A network blip causes a retry and you fear duplicate records. What is the correct fix?

Rate limits, backoff, idempotency and retries

Step 1 of 2