Idempotency

Where it shows up in real systems

• Background workers

  Workers absorb slow work such as emails, image resizing or payments reconciliation. Delivery is at-least-once, so handlers must be idempotent or duplicates will create side effects twice.

  In production: Celery, Sidekiq, AWS Lambda event source, Kubernetes Jobs

• Message queue

  A queue absorbs spikes: the API answers as soon as the message is stored, and workers drain the backlog at their own pace. Standard queues deliver at least once and may reorder; FIFO queues keep order but cap throughput. Messages that fail repeatedly go to a dead-letter queue.

  In production: Amazon SQS, RabbitMQ, Azure Service Bus, Google Cloud Tasks

• Payment provider

  Calls take hundreds of milliseconds, a small share fails transiently, and the provider rate-limits you. Never charge twice: send an idempotency key with each request, retry with backoff, and move the call out of the user request path when you can.

  In production: Stripe, Adyen, PayPal, Moneris, Square