A retryable job is safe only when the business action is idempotent_

Queues improve durability by retrying failures. They also repeat code. Without an idempotency strategy, the same retry can send duplicate emails, charge twice, or create two invoices.

“Exactly once” is usually a product requirement implemented over at-least-once delivery, not a switch in Redis.

What changes in practice_

Use a stable business key, record completion transactionally, make steps resumable, and send uncertain jobs to review instead of retrying forever.

• Choose a business-level idempotency key.
• Bound retries and backoff.
• Expose dead-letter work to operators.

Our take_

The durable advantage is not adopting the newest tool first. It is building the identity, state, evidence, and operating boundaries that let a real team own the system after launch.