Idempotency — design operations that are safe to retry

Network failures, timeouts, and retries can cause operations to execute multiple times. Without idempotency, this leads to duplicate charges, double-sends, or corrupted data.

Design operations to produce the same result regardless of how many times they run. Techniques: (1) Use idempotency keys — client generates a unique key per operation, server deduplicates. (2) Use PUT/PATCH over POST where possible (PUT is naturally idempotent). (3) Database: use UPSERT (INSERT ON CONFLICT UPDATE) instead of INSERT. (4) Queue processing: track processed message IDs. (5) Payment APIs: always pass an idempotency key. Check provider docs — Stripe uses Idempotency-Key header.

In distributed systems, exactly-once delivery is impossible. The practical solution is at-least-once delivery with idempotent handlers, which achieves effectively-once processing.