Retry strategy
A retry strategy defines which failures to retry, the waiting intervals and the limit on further attempts.
A retry strategy determines when to attempt a failed or unanswered operation again. It separates temporary disruption from errors requiring correction first and limits attempts or total duration.
In a fictional example, an integration waits 2, 4 and 8 seconds before three further attempts. These are example values, not universal settings. Added randomness can reduce simultaneous retries from many receivers. The destination's requirements must also be respected.
A missing product code does not become valid through waiting. A lost response may conceal an operation already completed. Before retrying, establish safe effects through idempotency or outcome reconciliation. Retrying alone does not correct the underlying error.
Sources
Related terms
- IdempotencyAn idempotent operation has the same intended effect on system state when repeated identically as when performed once.
- Rate limitingRate limiting caps how frequently a client may make requests under a defined rule.
- Server-sent eventsServer-sent events carry text notifications from server to client over HTTP, for example about the progress of a background job.
- Entity tagAn ETag identifies a particular representation version of an HTTP resource and supports conditional reads or changes.
- Cross-Origin Resource SharingCORS controls browser access to responses across origin boundaries. It replaces neither API login nor permission checks.
- Electronic Data InterchangeEDI transfers structured business documents between systems. Format, partner profile, data mapping and responses need to agree.
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.