Idempotency keys for safe API retries

Client retries a failed request (network timeout, server error) but the server already processed the original request. This causes duplicate charges, double-created resources, or duplicate messages.

Implement idempotency keys: (1) Client generates a unique key (UUID) and sends it as Idempotency-Key header. (2) Server stores the key with the response. On duplicate key, return the stored response. (3) Key storage: Redis with TTL (24-48h), or a database table. (4) For Stripe-like pattern: store key -> {status: processing} on first receipt, update to {status: complete, response: ...} when done. If a retry arrives while processing, return 409 or wait. (5) Only apply to non-idempotent methods (POST, PATCH). GET and DELETE are naturally idempotent. (6) Keys should be scoped per-user to prevent cross-user collisions.

Network failures make it impossible for the client to know if the server processed a request. Idempotency keys let the client safely retry by ensuring the server only processes each unique request once.