Short answer: to handle rate-limited webhook subscriptions in Node.js push queues, put the rate limit in the client, space or batch due events, retry failures with increasing delays, and make the reservation-expiry consumer idempotent. Choose the queue by the boundary you can replace later, not by whichever scheduler has the most knobs.

The concrete case is a reservation held for a fixed window: an appointment slot, an intake slot, or a lab collection slot should become available after the hold expires. If 12,000 holds become due together and the endpoint can safely accept 20 deliveries per second, the arithmetic says roughly 10 minutes of steady delivery before retries. The burst is the problem. The creation request is not the dominant operational cost; retained failed deliveries and repeated attempts are.

That is a useful distinction for a backend architect. I want the event contract, idempotency key, and retry classification to live in application code. The queue should carry work and expose pressure.…