Short answer: A marketplace renewal reminder should enter the dead-letter queue when another attempt cannot finish before its business deadline; use at-least-once delivery, a stable idempotency key, exponential backoff with jitter, and explicit redrive rather than retrying forever.
A queue can accept every job and still fail the business requirement if retries wake after the offer, reservation, or renewal window has closed. Conversely, retrying forever can deliver a reminder that is technically successful and commercially wrong. Backoff controls pressure. It does not create a delivery guarantee.
The business deadline defines the delivery contract
Start with three guarantees, each narrow enough to test. First, an accepted reminder is durably represented by one logical delivery ID. Second, attempts may repeat, so the consumer must treat that ID idempotently. Third, the scheduler will not begin a new automatic attempt when its conservative completion estimate crosses the business deadline.
Exactly-once delivery is the wrong contract at an HTTP boundary. A worker can send a request, lose the response, and have no reliable way to distinguish “the receiver committed it” from “the receiver never saw it.” Deleting the queue item risks loss; retrying risks a duplicate. At-least-once plus receiver-side idempotency is the defensible choice.
