RabbitMQ Lazy Queue Memory Strategy 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.