What a Stalled Consumer Does to the Erlang VM
Queue depth is invisible until a consumer dies or a downstream dependency stalls — then messages pile up and RAM pressure follows two separate curves. Raw payload is straightforward: backlogMillions × payloadSizeKB converted to GB. Per-message metadata is where queue type matters enormously: classic queues carry roughly 200 bytes of Erlang VM bookkeeping per message, while quorum queues carry roughly 2,000 bytes — a 10x jump driven by Raft log indexes and the in-memory state tables quorum queues maintain for consensus. At the default 5 million message backlog, that difference alone is the gap between a few GB and tens of GB of metadata overhead.
Classic vs Quorum Is a Real Tradeoff, Not a Default You Should Ignore
- Classic queues: Lower per-message memory footprint, but a node crash can lose unmirrored messages — no consensus protocol backs them.
- Quorum queues: Raft-replicated across nodes for durability, at the cost of roughly 10x the per-message RAM overhead modeled here — appropriate when message loss is unacceptable, expensive when it isn't.
- The 32GB threshold: This tool flags the total in red above 32GB of required RAM, and sizes the recommended VM with a 50% headroom multiplier (
totalRAM × 1.5) on top of the raw calculation, because the Erlang VM's own scheduler and connection-handling overhead needs room beyond just message storage.