SimpleQ vs RabbitMQ
RabbitMQ is a mature, capable broker — native consumer acks, rich exchange routing, dead-letter exchanges, priority queues. But you run it: provisioning, clustering, upgrades, monitoring, and keeping consumers connected. SimpleQ trades broker operations for a managed service purpose-built for webhook delivery to AI and API-heavy backends — push-to-webhook delivery with no long-lived consumers, backpressure that never burns a retry attempt, per-queue HMAC signing of the delivered payload, publish-boundary idempotency, and queue templates for LLM workloads, all included.
| Feature | SimpleQ | RabbitMQ |
|---|---|---|
| Managed | Yes — no infra to run | No — self-host the broker (or pay for managed RabbitMQ like CloudAMQP) |
| Delivery model | Push (webhook POST) | Push or pull — broker pushes to subscribed consumers (basic.consume) or apps poll (basic.get); both need long-lived AMQP connections |
| Retries | Configurable backoff (exponential/fixed) | No native backoff — requeue/nack redelivers immediately; delayed retry needs dead-letter + TTL or the delayed-message plugin |
| Rate limiting | Per-queue fixed-window, built-in | Consumer prefetch (QoS) limits in-flight messages — not a time-window rate limit |
| Ack mode | Three-signal protocol: ack (success), nack (failure with retryable flag), defer (backpressure — redelivers without burning attempts). Once the callback returns 200, the outcome is guaranteed. | Native consumer acks: basic.ack / basic.nack / basic.reject, with a requeue flag. Robust, but no attempt-budget or built-in backpressure-without-burning-retries semantic. |
| Backpressure | 429/503/529 auto-defers with Retry-After relay. Ack-mode /defer does the same. Neither burns a retry attempt — a job can ride out 100 consecutive 429s and still complete. | Prefetch + nack/requeue, or TCP back-pressure when consumers are slow. No Retry-After relay and no notion of retries you don't want to count. |
| Dead-letter queue | Built-in with single + bulk replay via API and dashboard | Native dead-letter exchanges (DLX) route rejected/expired messages; replay = re-publish from the DLQ (manual or via shovel/tooling) |
| Idempotency | Publish-boundary dedup — returns existing job ID on duplicate, safe-to-retry publishers | No built-in dedup; publisher confirms guarantee the broker got the message, but duplicate suppression is on you (or the dedup plugin) |
| Queue templates | template: "anthropic" or "openai" — one field configures ack mode, timeout, and backoff tuned for each provider's API | None |
| Per-job audit trail | Full attempt history: status, error, HTTP code, timestamp per attempt | No per-message attempt history; management UI shows queue/message stats, deeper tracing needs the firehose/tracer plugin or external tooling |
| Webhook signing | HMAC-SHA256 with per-queue secret — a leaked secret affects one queue, not the org | N/A — broker delivery is over an authenticated AMQP connection (TLS + SASL), not a signed HTTP payload to your endpoint |
| AI workload support | Anthropic and OpenAI queue templates, seconds convention matching provider Retry-After headers, ack mode for long LLM calls | None (general-purpose broker) |
| Routing topologies | Direct publish to a named queue | Rich — direct / topic / fanout / headers exchanges with bindings and routing keys |
| Protocols | REST publish, HTTP push delivery | AMQP 0-9-1 / AMQP 1.0, plus MQTT and STOMP via plugins |
| Priority queues | No | Yes (x-max-priority priority queues) |
| Dashboard | Built-in real-time dashboard | Management UI plugin (queues, connections, message rates) |
| Pricing | Free during early access | Free (OSS) + hosting/ops cost, or managed RabbitMQ pricing (e.g. CloudAMQP) |
When to choose SimpleQ
- You don't want to operate a broker. No clustering, no upgrades, no disk-alarm or memory-watermark tuning, no keeping consumer connections alive — SimpleQ is fully managed.
- You want push delivery to a plain HTTP endpoint. With RabbitMQ you run long-lived consumers holding AMQP connections; with SimpleQ your worker is a webhook you can deploy anywhere, in any framework.
- Your downstream APIs return 429s and you need backpressure that doesn't cost you a retry. RabbitMQ's nack/requeue and prefetch help with flow control, but there's no retry-budget concept — SimpleQ's defer holds the job and redelivers after the Retry-After delay with no attempt burned, so a job can ride out 100 consecutive 429s and still complete.
- You want delayed, backed-off retries out of the box. In RabbitMQ that means dead-letter + message TTL or the delayed-message plugin; in SimpleQ it's
retrieswith exponential/fixed backoff configured per queue. - You want one POST to configure a production-ready AI queue.
template: "anthropic"or"openai"sets ack mode, timeout, and backoff tuned for each provider's API — and durations follow the seconds convention that matches provider Retry-After headers. - You want per-job audit trails — status, error, HTTP code, and timestamp for every attempt — plus DLQ with single and bulk replay from the API and dashboard, rather than wiring DLX topologies and re-publishing from the dead-letter queue by hand.
- You want HMAC-SHA256 signing of the delivered payload with a per-queue secret, so a leaked secret affects one queue, not the org.
When to choose RabbitMQ
- You need rich routing topologies — topic/fanout/headers exchanges, bindings, and routing keys — to deliver one message to many queues by pattern.
- You need broker-native features SimpleQ doesn't have: priority queues, strict per-queue ordering with a single consumer, or protocol flexibility (AMQP, MQTT, STOMP) for IoT and interop.
- You want a self-hostable, open-source broker with no vendor dependency and full control over the messaging internals — including its native publisher confirms, consumer acks, and dead-letter exchanges.
Migrating from RabbitMQ?
Your processing logic stays the same — the shell changes. With RabbitMQ, a consumer holds an AMQP connection, pulls messages, and calls basic.ack / basic.nack. With SimpleQ, you expose a webhook endpoint that receives each job as an HTTP POST: return 2xx on success, or use ack mode for long-running work — return 200 immediately, then call /ack, /nack, or /defer when the work resolves. RabbitMQ's nack-with-requeue maps to SimpleQ's nack (with a retryable flag); its dead-letter exchange maps to SimpleQ's built-in DLQ with replay. The infrastructure you drop: broker provisioning, clustering, upgrades, monitoring, and consumer-connection management. What you gain: managed backpressure that never burns retries, per-job audit trails, DLQ replay from the API and dashboard, and per-queue signing secrets. If you're calling LLM APIs, start with template: "anthropic" or "openai".