RabbitMQ Lazy Queue Memory Strategy Prompt
Decide whether lazy queue behavior (disk-first message storage) fits a deep-backlog workload, and configure it without tanking throughput on hot paths.
- Target user
- Platform engineers managing memory-pressured RabbitMQ clusters
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has used lazy queues to survive deep message backlogs without tripping memory alarms. Help me decide if lazy mode fits my queues and configure it. I will provide: - The workload per queue: typical depth, worst-case backlog, message size, and publish/consume rates [DESCRIBE] - Why memory is a concern: alarm history, node RAM, how many queues share the node [DESCRIBE] - Latency sensitivity: is this a hot real-time path or a buffer/batch queue? [DESCRIBE] - Broker version (lazy queue mode applies to classic queues; quorum queues already store on disk) [DESCRIBE] Your job: 1. **Confirm lazy is the right tool** — lazy queues page messages to disk eagerly to keep RAM flat under deep backlogs, trading per-message latency for memory safety. If the queue is shallow and latency-sensitive, lazy mode hurts. Tell me plainly when a quorum queue (already disk-based) is the better answer instead. 2. **Per-queue, not global** — recommend applying `queue-mode: lazy` via a policy scoped to the buffer queues that actually go deep, not the whole vhost. Explain why hot, shallow queues should stay default. 3. **Throughput impact** — quantify the trade: lazy queues hit disk on the publish and consume path, so steady-state throughput drops versus a RAM-resident queue. Frame when that cost is acceptable (backlog survival) and when it isn't (low-latency RPC). 4. **Disk and version reality** — note that on modern RabbitMQ the classic queue v2 storage and quorum queues change this calculus, and that lazy mode is most relevant for classic queues prone to memory blowups. 5. **Validate** — what to watch: node memory staying flat during a synthetic backlog, queue depth, and consume-side latency before/after. Output as: (a) lazy-vs-quorum verdict with the deciding factor, (b) the policy command scoping lazy mode to the right queues, (c) the throughput/latency trade quantified for my workload, (d) the metrics that confirm memory stays bounded. Apply lazy mode via a scoped policy on staging and drive a synthetic deep backlog before production. Confirm memory stays flat AND that consume-side latency is acceptable — lazy mode can quietly slow a latency-sensitive consumer that was fine in RAM.
Why this prompt works
Lazy queues exist for one job: keeping node memory flat when a queue goes deep, by storing messages on disk eagerly instead of holding them in RAM. That trade is genuinely useful for buffer and batch queues that occasionally back up to millions of messages — and genuinely harmful for shallow, latency-sensitive queues that were perfectly happy in memory. This prompt’s first job is making that fit decision explicitly, including the increasingly common answer that a quorum queue, which is already disk-based, is the better tool than bolting lazy mode onto a classic queue.
The per-queue scoping point matters because the failure mode is applying lazy mode broadly via a vhost-wide policy and then wondering why a hot RPC path got slow. The prompt insists the policy targets the queues that actually go deep, leaving hot shallow queues on the default mode. That single discipline prevents the most common lazy-mode regression.
The throughput honesty is what makes the recommendation trustworthy. Lazy queues hit disk on both publish and consume paths, so steady-state throughput drops — the prompt quantifies that against the workload instead of selling lazy mode as free. It also flags that modern classic v2 storage and quorum queues have shifted this calculus, so the answer isn’t reflexive. The staging guardrail demands proof that memory stays flat under a synthetic backlog and that consume latency is still acceptable, which is the only honest way to sign off on the trade.