Short answer: use Redis when failed reservations need low-latency retries and the workload is small enough for the team to own failure management; use Amazon SQS when built-in retries and dead-letter queues matter more than the shortest path back to a worker. For a game reservation held for 10 minutes, the deciding constraint is latency versus the amount of retry machinery the application must maintain.

This is an architecture decision record, not a queue popularity contest. The invariant is simple: a reservation may expire after its hold window, but a late or duplicated worker must not turn a completed purchase back into an expired one.…