Use a delayed queue to wake up reservation expiry, then let a retryable worker make the final decision. The operational rule is simple: set a bounded consume timeout, record why a webhook was slow, and send persistent failures to a dead-letter queue (DLQ) instead of silently extending a customer hold.

This matters in fintech. A reservation that stays open after its fixed hold window can distort available balance, inventory, or payment intent state. The expiry message is not the source of truth; it is a prompt to check the reservation and close it safely.

Option Pick it when Operational trade-off

Amazon SQS with a worker You want a managed queue and can accept AWS-specific operations Dead-letter handling and delivery behavior fit AWS well, but the surrounding system is another set of AWS resources to operate

RabbitMQ You need broker-level routing and control over deployment Flexible exchanges and acknowledgements are useful, while broker capacity and recovery become your responsibility

BullMQ with Redis…