{
  "video_id": "reddit_1t98whm",
  "channel_slug": "programming",
  "channel_handle": "r/programming",
  "title": "Idempotency Is Easy Until the Second Request Is Different",
  "url": "https://www.reddit.com/r/programming/comments/1t98whm/idempotency_is_easy_until_the_second_request_is/",
  "external_url": "https://blog.dochia.dev/blog/idempotency/",
  "upload_date": "20260510",
  "published_at": "2026-05-10T14:46:53+00:00",
  "transcript": "\n\n--- Top Comments ---\n\n\n[628 upvotes] Isn't the title an oxymoron? If the second request is different, you are no longer talking about idempotency.\n\n[192 upvotes] This is a classic example of solving the wrong problem. Is it still called “idempotency” if you want idempotent behavior for 2 different requests? How different are the 2 requests?\n\nWhat should happen if a buggy client sends you two distinct operations with the same idempotency key? In this author’s view you should design this new convoluted system. In reality you should simply tell the buggy client that they have done something wrong and whatever they did may not be reversible.\n\n[104 upvotes] Half of this is not about idempotency, it's about resilience generally. \"But what if the operation fails halfway\" - what's that got to do with idempotency? Either you fail synchronously and the client gets a 500, or you do some async system and the client sees through later requests that this job never reaches a completed state. How the initiating request is idempotent has nothing to do with this.",
  "transcript_chars": 1063,
  "ingested_at": "2026-05-12T11:04:45.800440+00:00",
  "source": "reddit",
  "yt_meta": {
    "score": 71,
    "upvote_ratio": 0.63,
    "num_comments": 55,
    "author": "Either_Collection349",
    "is_self": false
  }
}