Magento's silent RabbitMQ backlogs, from late order emails to stuck bulk jobs, often trace to missing or stalled consumers

Publishing a message is cheap. A topic publish inside a Magento request hands the payload to the broker and returns ^[4]. Sending the email, cancelling the reservation, closing the bulk operation: all of that happens later, in a separate single-threaded PHP process that your frontend timing never touches ^[4][17]. The request the customer cared about already succeeded, which is why the backlog stays quiet until the symptoms surface somewhere else, as an email an hour late or a bulk operation stuck on "processing" ^[2].

So the audit reads a different column. `rabbitmqctl list_queues name messages messages_ready messages_unacknowledged consumers` gives depth and consumer count per queue in one line ^[7]. The MageVanta guide reads four cases off it: `messages_ready` high with consumers present means slow handlers or too few workers ^[10]; `messages_unacknowledged` high means consumers are holding messages mid-processing, crashed mid-message, or looping on redelivery ^[11]; an active memory or disk alarm means the broker is throttling both sides ^[12]; and consumers at zero on a queue that should always drain means the process died and nothing restarted it ^[13].

Two of those four cases point to something other than a tuning fix. Zero consumers is a process-manager problem, per the same guide ^[13]. The alarm case invalidates the rest, because tuning handlers while the broker sits in flow control measures the alarm rather than the handler ^[12]. Check alarms with `rabbitmq-diagnostics alarms` before you count workers ^[8].

The guide publishes no throughput figures, and that is the defensible position. Worker count raises throughput only until the handler hits its real bottleneck, which the guide puts at database writes, API calls or the filesystem ^[17]. The `multiple_processes => 3` in the example env.php is a number about someone else's handler ^[18]. What transfers is the method: raise the process count for one queue until per-message duration stops improving, then stop.

The shell-and-ampersand version of the same idea is worth pricing. Three backgrounded `queue:consumers:start async.operations.all --max-messages=10000` processes will handle 30,000 messages between them and then be gone ^[1], because a consumer exits when the queue empties or when max-messages is reached ^[15][20]. Setting `consumers_wait_for_messages => 1` in app/etc/env.php covers the empty-queue half of that behaviour ^[16]. The ampersands in that snippet stage a demonstration for illustration only. Declaring the process count in env.php is the durable form ^[18], and 2.4.6 and later moves consumer settings into app/etc/consumers.xml ^[19].

The tooling to run this audit already exists in Magento. Magento already tells you the intended roster with `bin/magento queue:consumers:list`, and `ps aux | grep queue:consumers` tells you which of them are alive right now ^[9]. Queue ownership is declared per module in queue_consumer.xml, so the roster is knowable before any incident ^[3]. The artifact worth building is dull: consumer name, the number of processes that should be running for it, and the thing that restarts them. Compare that against list_queues output on a schedule ^[7]. That comparison surfaces a dead consumer within minutes; skip it, and the first sign is someone asking why inventory_reservation has grown, or why the bulk and operation tables are exploding while async.operations.all sits still ^[14].