Retry with backoff

Retry with backoff is the pattern of re-attempting a failed operation after a delay, with each successive delay longer than the last - seconds, then minutes, then hours. The "backoff" is the widening gap; it gives whatever failed progressively more room to recover before the next attempt.

The pattern exists because most failures in distributed systems are transient. An API returns a momentary 500, a token needs refreshing, a network path flaps. Retrying immediately often works, but retrying immediately in a tight loop makes things worse - a struggling service hit by a wall of instant retries from every client stays down longer. Spreading retries out converts a brief outage into, at worst, a brief delay.

Backoff pairs naturally with asynchronous processing. If the user-facing request is acknowledged first and the risky work (an API write, a delivery) happens in a background worker, a failure costs nothing visible: the worker simply schedules the next attempt and moves on. The essential companions are a bounded retry schedule - so nothing loops forever - and a log, so a human can see what happened when the schedule runs out.

SheetLink Forms delivers this way. Submissions are accepted and screened, then an asynchronous worker writes the row directly to the Google Sheets API or Microsoft Graph. If a write fails - a token hiccup, a Google or Microsoft outage - the worker retries at 5 minutes, 30 minutes, and 2 hours, and every attempt is visible in the delivery log in the dashboard. The submission itself is already safely stored, so a failed delivery is a delay, not a loss.

The delivery pipeline is drawn out on how it works, with worker behavior detailed in the docs.