US/EU Property Webhooks: Compare SQS Queue Cost, Rate Limiting, Delayed Jobs, Retry, DLQ

Short answer: To compare SQS and other queue choices for US/EU property webhooks, judge queue cost alongside rate limiting, delayed jobs, retry, and DLQ recovery; for an expiring reservation, the option that meets the delivery SLO is usually cheaper operationally than the option with the lowest unit price.

The concrete job is easy to describe and surprisingly easy to get wrong: a property-management system places a reservation on hold, sends a webhook to another service, and must expire that hold when the fixed window ends. The sender may burst. The receiving API may allow only a smaller rate. A worker therefore needs delayed delivery, bounded retries, and a dead-letter queue (DLQ) that an operator can actually inspect. The comparison set might include SQS, RabbitMQ, CloudAMQP, Upstash QStash, and Cloud Tasks, but naming those systems does not answer the engineering question; each must be tested against the same reservation state machine, regional boundary, payload shape, and recovery runbook.

I would treat this as an operational-recovery decision, not a queue shopping exercise. The queue is allowed to deliver an event more than once. The application is not allowed to expire the same reservation twice.

How should a property team compare queues for webhook rate limiting and delayed retries?

Start with the event contract. Give each hold-expiration event a stable identifier, a reservation identifier, an intended expiry time, and the source version that created it. The consumer verifies the request, checks whether that event has already produced its business effect, and records completion durably before acknowledging the message. If the same event arrives again, the consumer returns success without applying the expiry a second time.

That ordering is the important part. Acknowledging before the database transaction commits can lose work. Acknowledging after the business mutation but before recording the event can repeat work. The exact transaction shape depends on the datastore, but the invariant does not: the completion record and the reservation state must agree. I write down the failure sequence before choosing a queue: an event arrives, the worker gets a 429, the retry timer advances, the hold is confirmed by another request, and the old expiry event finally runs. The correct result is a durable no-op with an observable completion, not a second state transition and not an event silently discarded because its timestamp looks old.

Rate limiting belongs at the boundary where the downstream contract is known. If the booking service accepts 10 requests per second and the webhook stream arrives at 20, retries cannot create capacity. They only move pressure around. Capacity planning should therefore include peak arrival rate, permitted drain rate, maximum acceptable queue age, retry attempts, payload size, and the time an operator needs to redrive a failure.

One short rule.

Keep the retry budget smaller than the period in which an expired hold can still cause a customer-visible inconsistency. After the budget is exhausted, move the event to a DLQ with its last error, attempt count, timestamps, and reservation identifier. A DLQ is an operational work list, not an archive that nobody owns.

The recovery path matters more than the queue's unit price

For a US/EU deployment, region is one input, not the whole decision. A team has to define where event data is stored, where workers run, which network boundary the receiver crosses, and what happens when one region is unavailable. The same nominal queue cost can produce different operational work if the design requires cross-region forwarding, duplicate suppression, or separate recovery procedures.

The cheapest option on a spreadsheet is often the one with the most unpriced ownership. A self-hosted broker requires capacity planning, upgrades, backups, access control, paging, and recovery drills. A managed queue removes much of that broker operation, but it does not remove the need to make the consumer idempotent or to test the DLQ procedure. A hosted broker sits between those models: less infrastructure ownership than self-hosting, while retaining broker-specific semantics and another service boundary to operate.

I would price a candidate with a workload envelope: peak events per second, average payload bytes, number of attempts, retention days, regional copies, and expected DLQ rate. Then add the human cost of a failed redrive. Current pricing pages change, and I’m not sure a published unit price alone can answer “cheapest” for a workload whose main cost is recovery time.

A reservation hold needs a deadline, not just a delayed message

The hold-expiration timestamp belongs in the event and in the reservation record. A delayed queue message is a delivery mechanism; it is not proof that the hold is still eligible to expire. When a guest extends a hold, confirms a booking, or cancels it, the consumer must compare the event version and current reservation state before changing anything.

That check protects against an old delayed message. It also makes retries safe. A worker can receive an event after the intended time, find that the reservation has already been confirmed, and acknowledge the event as a valid no-op. This is different from swallowing an error: the business state has already reached a later, authoritative state.

For long hold windows, an external scheduler may create a task that later publishes to the queue. For short windows, a queue delay may be enough. The boundary should be explicit because a scheduler and a queue have different failure modes: missed trigger handling, duplicate trigger handling, retention, clock precision, and operational visibility. GitHub Actions documents scheduled workflow triggers, but that documentation should not be treated as a general-purpose reservation timer; the application still needs a durable state check when the task runs.

The failure I would test first is a downstream 429 after the worker has received the event. The worker must leave the business effect unapplied, return a retryable result, and preserve enough metadata for the next attempt. A 400 caused by a permanently invalid payload should follow a different path and reach the DLQ quickly. Mixing those classes turns a transient outage into a backlog, or turns a poison event into endless traffic.

That is the part a pricing table cannot model.

What should the Go consumer verify before it acknowledges work?

This small handler shows the safety boundary. The header names are application conventions; RFC 2104 defines the HMAC construction, while the sender's contract defines how the signature is encoded. The in-memory map is intentionally a demonstration. Production completion records must be durable and must participate in the same transaction as the reservation mutation where the datastore supports that boundary.

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "crypto/subtle"
    "encoding/hex"
    "io"
    "net/http"
    "sync"
)

type consumer struct {
    mu        sync.Mutex
    completed map[string]struct{}
    secret    []byte
}

func (c *consumer) handle(w http.ResponseWriter, req *http.Request) {
    if req.Method != http.MethodPost {
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
        return
    }

    body, err := io.ReadAll(io.LimitReader(req.Body, 256*1024))
    if err != nil {
        http.Error(w, "invalid body", http.StatusBadRequest)
        return
    }

    provided, err := hex.DecodeString(req.Header.Get("X-Webhook-Signature"))
    if err != nil {
        http.Error(w, "invalid signature", http.StatusUnauthorized)
        return
    }

    mac := hmac.New(sha256.New, c.secret)
    _, _ = mac.Write(body)
    want := mac.Sum(nil)
    if len(provided) != len(want) || subtle.ConstantTimeCompare(provided, want) != 1 {
        http.Error(w, "invalid signature", http.StatusUnauthorized)
        return
    }

    eventID := req.Header.Get("Idempotency-Key")
    if eventID == "" {
        http.Error(w, "missing idempotency key", http.StatusBadRequest)
        return
    }

    c.mu.Lock()
    defer c.mu.Unlock()
    if _, ok := c.completed[eventID]; ok {
        w.WriteHeader(http.StatusOK)
        return
    }

    // Replace this section with a durable state change and completion record.
    c.completed[eventID] = struct{}{}
    w.WriteHeader(http.StatusOK)
}

The code does not decide whether an error is retryable; that policy belongs in the worker and queue configuration. It does demonstrate two checks that should happen before a successful acknowledgment: authenticate the bytes that arrived, then enforce a stable event identity. The production version should also validate the reservation state and event version inside the durable transaction.

Alert on queue age, retry volume, and DLQ growth. CPU is useful, but it is usually a late signal for this failure mode. Recovery is part of the design.

Where this queueing advice stops fitting

The catch is that a queue-centered design is not suitable when the workload needs independent replay by many consumers, a long-lived event log, or a workflow with fan-in and branching. Use a log-oriented system for replay requirements and a workflow engine for orchestration requirements. Use a pull-based delivery model when the receiver cannot be publicly reachable; a push webhook cannot solve a private-network boundary by itself.

It is also a poor fit when the business rule cannot tolerate at-least-once delivery and there is no durable place to record idempotency. In that case, fix the state model before comparing queue prices. A different queue will not make a non-repeatable side effect safe.

For this property-management scenario, my decision rule is narrow: select the smallest operational model that can enforce the downstream rate, preserve the expiry deadline, expose queue age, and let an operator redrive one event without guessing. Stick with a broker you already operate when its private-network or protocol requirements are real. Choose a managed shape when reducing broker on-call work is the stronger constraint. Either way, the reservation record remains the authority.

References

• RFC 2104, HMAC keyed-hashing for message authentication: https://www.rfc-editor.org/rfc/rfc2104
• GitHub Actions workflow schedule triggers: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows