Failed Reservation Jobs: Queue Retry, Rate Limiting, Dedup, and Idempotency

Short answer: The best queue for retrying failed reservation jobs is one you can migrate reversibly, rate-limit at execution time, and pair with an idempotent database transition.

The governing constraint is the expiration SLO. An e-commerce reservation must not expire before its fixed hold deadline, while a late retry must not preserve inventory indefinitely or race a completed checkout into the wrong state. Queue features matter, but they don't own that contract. The durable reservation record does.

Start with rollback.

Migrate the expiration path before choosing its permanent queue

A queue comparison is much less useful than a migration proof when the old scheduler already carries live holds. Put queue-specific operations behind a narrow delivery interface, deploy the idempotent state transition first, and keep the current producer available while the new consumer runs against copied job intent. Consider a reservation due at 14:05:00: the current path remains the only writer, while the candidate records that it would have attempted expiration at 14:05:01, waited behind the merchant limiter, and reached the same terminal decision at 14:05:03. Compare those decisions by reservation ID and original deadline, including no-ops after checkout. A mismatch blocks the traffic shift; it is evidence about semantics, not permission to let both consumers write. During that observation period, only one path may mutate reservation state. This ordering separates business correctness from delivery mechanics and gives the team a clean reversal point without manufacturing a customer-visible experiment.

Every expiration job needs a stable reservation ID and the original expires_at. It must never derive a fresh deadline on retry. Recomputing the hold window would change the customer contract, not repeat the same work, and no FIFO promise or deduplication window can repair that mistake later. The payload can also carry an attempt count for retry policy, but the stored reservation remains authoritative for both deadline and state.

Define the rollback triggers before shifting traffic: expiration lateness consuming the error budget, oldest eligible job age growing beyond the drain plan, or unexplained divergence between shadow decisions and committed outcomes. Rollback means stopping new production into the candidate path and resuming the prior producer; it does not mean deleting queued intent. Stable job identities let operators reconcile both paths without treating a duplicate as a second business action.

Be conservative.

Migration speed is not the SLO.

How should a queue retry failed jobs with rate limiting, dedup, and idempotency?

Use the queue to deliver intent, a shared admission limiter to protect the constrained operation, and one atomic database predicate to decide whether expiration is legal. A worker may receive the same job twice or receive it after checkout wins. Both are ordinary delivery outcomes. The reservation store must change held to expired only when the stored deadline is due; paid, cancelled, already expired, and not-yet-due records are terminal no-ops for this handler.

Put the limiter beside the constrained call rather than only at the producer. Producer pacing doesn't account for redelivery, a released backlog, or several worker pools calling the same inventory boundary. If the practical limit is per merchant or warehouse, use that dimension as the limiter key so one busy tenant cannot consume every permit. A global limiter is appropriate only when the downstream constraint is actually global.

Retries need a budget tied to the expiration SLO. For a test profile that permits 40 inventory writes per second, a simulated 429 should defer the attempt with bounded backoff and jitter while preserving expires_at; 40 is test data here, not a claimed product limit. Invalid input should terminate, and attempts that exhaust the retry budget should move to a quarantine path where an operator can inspect and safely replay them. Dead-letter routing is a standard broker mechanism for redirecting messages that cannot remain on their current queue.

Deduplication and idempotency solve different problems. Dedup reduces repeated scheduling or delivery work, perhaps using a key such as expire:<reservation_id>:<expires_at>. Idempotency protects the business transition even when a duplicate arrives outside the dedup window or through another recovery path. I don't accept an "exactly once" label as a substitute for that database invariant — the claim needs to survive a payment-versus-expiration race.

Make one atomic transition the worker contract

The handler should be testable without a broker. In this Go example, ExpireIfHeld represents one atomic store operation; queue adapters translate ErrNotDue and ErrRateLimited into their own delay or retry primitives, and acknowledge only after the handler returns a terminal result.

package expiry

import (
    "context"
    "errors"
    "fmt"
    "time"
)

var (
    ErrNotDue     = errors.New("reservation is not due")
    ErrRateLimited = errors.New("rate limited")
)

type Job struct {
    ReservationID string
    ExpiresAt     time.Time
}

type Limiter interface {
    Allow(ctx context.Context, key string) (bool, error)
}

type ReservationStore interface {
    ExpireIfHeld(ctx context.Context, id string, dueAt time.Time) (changed bool, err error)
}

type Handler struct {
    Limit Limiter
    Store ReservationStore
}

func (h Handler) Run(ctx context.Context, limiterKey string, job Job, now time.Time) error {
    if job.ReservationID == "" || job.ExpiresAt.IsZero() {
        return fmt.Errorf("invalid expiration job")
    }
    if now.Before(job.ExpiresAt) {
        return ErrNotDue
    }

    allowed, err := h.Limit.Allow(ctx, limiterKey)
    if err != nil {
        return fmt.Errorf("check admission: %w", err)
    }
    if !allowed {
        return ErrRateLimited
    }

    _, err = h.Store.ExpireIfHeld(ctx, job.ReservationID, job.ExpiresAt)
    if err != nil {
        return fmt.Errorf("expire reservation: %w", err)
    }
    return nil
}

The store predicate must include both expected state and deadline in the same atomic operation. Reading held, then updating in a separate operation, leaves a race in which checkout can commit between those steps. Recording a dedup key separately has a similar gap. The queue cannot rescue a non-atomic business model.

Keep the adapter boring. It maps a typed retry result to the candidate's scheduling operation, maps a terminal result to acknowledgement, and exports consistent attempt and delay metrics. Business code should not know whether delivery is standard at-least-once, grouped FIFO, a managed task dispatcher, or a Redis-backed worker queue. That boundary makes the comparison executable and reduces lock-in, although it won't erase semantic differences such as ordering scope or operator ownership.

Gate each delivery model with capacity and ownership evidence

Do not rank the shortlist by feature count. Reject any model that cannot pass the reservation workload proof under skew, because the primary decision is latency versus cost: paying for unused capacity can reduce backlog delay, while running close to the downstream limit saves capacity expense but leaves little recovery margin.

Capacity planning turns that table into a decision. Let A be eligible expirations arriving per second, R the allowed completion rate, and B the eligible backlog. Stability requires long-run completion capacity above arrivals. When R > A, the optimistic drain time after a burst is B / (R - A); retries consume permits too, so the observed result will be worse. When R <= A, more workers create contention rather than recovery margin. Raise the constrained capacity, reduce arrivals, partition the limit, or renegotiate the SLO.

The catch is explicit. Grouped FIFO is not suitable when unrelated reservations share a hot key and ordered execution costs too much lateness; use unordered duplicate-safe delivery instead. Managed dispatch is not suitable when workers require independent pull control; use a general queue. A self-hosted worker queue is not suitable when persistence and recovery lack a named owner; choose a managed operational boundary. I'm not sure which has the lowest total cost until arrival distribution, payload size, retention, replay volume, idle capacity, and operator time are measured. Your mileage may vary.

Verify the SLO, switch traffic, and rehearse rollback

Test invariants before throughput. Create a held reservation with a known deadline, deliver early, and assert no state change. Deliver at the deadline twice and assert one transition. Race payment against expiration and assert one legal terminal state. Simulate a 429, advance a controlled clock, and verify that retry timing stays inside its budget without changing expires_at. Then replay a quarantined job and confirm the same predicate still protects a terminal reservation.

Skew is next. Run ordinary arrivals below the rate, a burst above it, and sustained arrivals near it while retries are present. A uniform generator can hide the merchant or warehouse partition that determines fairness. Measure completion latency from expires_at, then separate queue wait, limiter wait, handler duration, retry delay, and final outcome; otherwise a dashboard can identify lateness without locating its cause.

Track expiration-lateness percentiles, oldest eligible job age, eligible arrival rate, transition and terminal no-op rates, limiter denials, attempts, quarantined jobs, consumer saturation, and projected drain time. Don't page on every retry. Page when customer-visible lateness or lost recovery margin consumes the error budget. Queue depth alone is weak: a large backlog can be safe with enough drain capacity, while a small hot partition may already miss the SLO.

After the shadow results agree, shift a small slice of producers, compare the same SLO signals, and increase traffic only while rollback margin remains. Keep the previous path ready until the candidate has passed duplicate delivery, retry exhaustion, skew, and restore exercises. The final choice is the least expensive operating model that still proves the expiration SLO under recovery load, not the queue with the longest feature list.

References

• https://www.rabbitmq.com/docs/dlx
• https://cloud.google.com/pubsub/docs/overview