RabbitMQ Single Active Consumer Ordering Prompt
Use single active consumer (SAC) to preserve strict message ordering with hot-standby failover, and understand exactly what ordering guarantee you get versus what you don't.
- Target user
- Backend and platform engineers needing ordered processing
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has used single active consumer (SAC) to get ordered processing on RabbitMQ. Help me apply it correctly and understand its limits. I will provide: - The ordering requirement: strict per-queue order, per-key order, or just "mostly in order"? [DESCRIBE] - The workload: message rate, processing time, and whether redelivery on failover is tolerable [DESCRIBE] - The consumer topology: how many consumers connect, and what happens to throughput if only one is active [DESCRIBE] - Queue type (SAC is supported on classic, quorum, and streams with differences) and broker version [DESCRIBE] Your job: 1. **Set the right expectation** — SAC guarantees only ONE consumer receives messages at a time, with another taking over on failure. It gives ordered delivery to a single consumer; it does NOT make a multi-consumer pool ordered, and it does NOT prevent reordering caused by requeue/redelivery. State plainly what guarantee my use case actually gets. 2. **Throughput trade** — with SAC, only one consumer works while the rest stand by, so you lose horizontal parallelism on that queue. If I need ordering AND throughput, recommend partitioning by key across multiple queues, each with its own SAC, instead of one ordered queue. 3. **Failover behavior** — explain when the active consumer is replaced (cancel/disconnect), the in-flight redelivery on failover, and how that can break strict ordering unless consumers handle redelivery idempotently. 4. **Per-queue-type differences** — note SAC semantics on quorum queues vs classic vs streams, and which gives the cleanest ordering story for my version. 5. **Validate** — confirm via `rabbitmqctl list_consumers` showing one active, simulate a failover, and verify ordering and idempotency under redelivery. Output as: (a) the precise ordering guarantee for my case, (b) the SAC config (`x-single-active-consumer`) or partition-by-key recommendation, (c) the failover/redelivery handling, (d) how to verify active-consumer count and ordering. Test SAC failover on staging by killing the active consumer and watching the standby take over. Confirm ordering holds AND that redelivered in-flight messages don't violate your ordering or processing assumptions before relying on it in production.
Why this prompt works
Single active consumer is the feature people reach for when they hear “ordered processing,” and it’s the feature they most often misunderstand. SAC guarantees exactly one consumer receives messages at a time with hot-standby failover — that’s it. It does not make a consumer pool ordered, and it does not stop reordering from requeue or redelivery. This prompt’s first and most important job is stating the actual guarantee for the user’s specific case, because the gap between “SAC gives me ordering” and “SAC gives me single-consumer delivery with failover” is where ordering bugs are born.
The throughput trade is the practical fork in the road. With SAC, the standby consumers do nothing, so you’ve traded all horizontal parallelism on that queue for order. When a workload needs both, the right pattern is partition-by-key across multiple queues each running its own SAC — and the prompt steers toward that instead of letting someone funnel everything through one serialized queue and then complain about throughput.
The failover and idempotency section closes the real gap: when the active consumer dies, its in-flight unacked messages redeliver to the new active consumer, which can reorder or reprocess them. Strict ordering only survives that if consumers are idempotent and redelivery-tolerant. The staging guardrail makes the failover a deliberate test — kill the active consumer, watch the standby, verify ordering holds under redelivery — which is the only way to know the guarantee is real before production depends on it.