Asynchronous processing

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

• Email and SMS provider

  Delivery is slow and can fail, so send from background workers, never while the user waits. Providers throttle senders and track bounces; a burst of password-reset emails can hit the limit.

  In production: Amazon SES, SendGrid, Mailgun, Twilio, Postmark