{
  "id": 12983027,
  "title": "To Retry or Not to Retry: Safe Retry Logic with Exponential Backoff, Jitter and Idempotency Keys",
  "url": "https://urgent.news/2026/10/08/to-retry-or-not-to-retry-safe-retry-logic-with-exponential-backoff",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-08T23:44:37.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/eme_gug_0821b41b948be6516/to-retry-or-not-to-retry-safe-retry-logic-with-exponential-backoff-jitter-and-idempotency-keys-4d01"
  },
  "original_language": "en",
  "account": "In a previous incident, the team faced a notable issue where a payment provider took about 30 seconds to respond, and during that time, their system sent four requests to charge the same order. This happened due to three layers of retry: the client's SDK, the API service, and the job queue behind it. While no single layer was at fault, the outcome was disastrous. From that experience, they learned that retry is not an added feature to ensure reliability. In fact, if it leads to incorrect behavior, it can be more dangerous than not retrying at all.\n\nThis article shares their approach to retry logic in production: when to retry, how to do it without overloading their system, and how to ensure safe retry for requests with side effects. The first question to ask before writing any code is whether the request should be retried. Before writing any code, they need to answer two questions: is this a temporary error (transient) or something else? Does the 429 (Too Many Requests), 503 (Service Unavailable), 504 (Gateway Timeout), or 400/401/404/422 status code indicate a transient error? 400, 401, 404, 422 do not benefit from multiple retries. Is this request idempotent, or does it have an Idempotency-Key? HTTP GET, PUT, and DELETE methods are idempotent, while POST is not. Retrying a POST /charges request that timed out is the quickest way to charge a customer twice, as timing out doesn't mean the server hasn't processed the request. There's a chance the server already processed it, and the response simply didn't reach the client.",
  "summary": "Hồi trước team mình từng có một sự cố khá kinh điển: payment provider chập chờn khoảng 30 giây, và trong 30 giây đó service của bọn mình gửi 4 lần request charge tiền cho cùng một đơn hàng. Lý do là có 3 tầng cùng retry: SDK của client, service gọi API, và cả job queue phía sau. Không tầng nào sai nếu xét riêng, nhưng gộp lại thì thành thảm họa. Sau lần đó mình rút ra một điều: retry không phải…",
  "key_points": [
    "Determine if request is transient error or not before retrying",
    "Idempotent requests (GET, PUT, DELETE) can be safely retried",
    "POST requests lack idempotency, risking double processing on retry"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}