Building a Million‑Message‑Per‑Second RabbitMQ Service: Architecture, Scaling, and High Availability

Background – Leveraging RabbitMQ’s horizontal scaling and load‑balancing capabilities can push a messaging cluster to handle millions of messages per second, a technique previously explored by Google and other large‑scale push‑notification services.

RabbitMQ Overview – RabbitMQ implements the AMQP protocol and provides easy‑to‑use, scalable, highly‑available messaging for distributed systems. Core concepts include messages, queues, bindings, exchanges, brokers, virtual hosts, connections, and channels.

Cluster Modes – In the default (non‑mirrored) mode, queue data resides on a single node, causing a bottleneck if the node fails. Mirrored queues replicate data across multiple nodes, improving reliability at the cost of performance and network bandwidth.

How to Build a Million‑Level Service – Google’s experiment used 32 eight‑core VMs (30 RAM nodes, 1 disk node, 1 stats node) to achieve over 1.3 M messages/s production and consumption without noticeable memory pressure. Smaller clusters of 3‑7 nodes can also achieve good results.

RabbitMQ Sharding Plugin

To alleviate single‑queue bottlenecks, the sharding plugin (available from version 3.6.0) automatically creates partitioned queues across nodes. Enable it with:

rabbitmq-pluginsenable rabbitmq_sharding

When a new node joins, the plugin creates additional shard queues on that node, automatically routing new messages to the new shards.

The default exchange routing ("all or nothing") must be changed to a sharding‑aware exchange such as x-modulus-hash or a consistent‑hash exchange, which hashes the routing key to select a target queue.

Consistent‑Hash Sharding Exchange – This exchange type hashes the routing key and distributes messages evenly across queues, allowing manual creation of shard queues and supporting weighted distribution via numeric binding keys.

Reliability and High Availability Discussion

Use publisher confirms and consumer acknowledgments to guarantee delivery. Enable confirm mode on channels with confirm.select . Consumers must ack messages after successful processing; otherwise, messages can be re‑queued.

Heartbeats detect broken TCP connections, and persistent messages ensure data survives broker restarts. Mirror queues provide HA: a master and one or more slaves; if the master fails, a slave can be promoted.

Scenario 1 – Reliable Delivery – Use publisher confirms and consumer acks to ensure messages are persisted and processed.

Scenario 2 – Retry Mechanism – Implement dead‑letter exchanges (DLX) with x-dead-letter-exchange and x-message-ttl to move failed messages to a retry queue after a delay.

Scenario 3 – Delayed Tasks – Use a TTL‑configured queue with a DLX to implement scheduled execution of messages.

Scenario 4 – Cross‑Center Message Sharing – Enable the Federation plugin to replicate messages between brokers without a full cluster:

rabbitmq-pluginsenable rabbitmq_federation

rabbitmq-pluginsenable rabbitmq_federation_management

Federated exchanges pull messages from upstream exchanges based on defined bindings, while federated queues pull messages on demand.

Scenario 5 – High‑Availability Queues – Mirror queues across nodes; configure policies to control mirroring and promotion behavior (e.g., ha-promote-on-shutdown ).

Performance testing shows mirroring reduces throughput; increasing prefetch and adding more nodes can mitigate the impact.

Spring AMQP Integration – Spring AMQP provides AmqpTemplate and related APIs to interact with RabbitMQ, abstracting protocol details and allowing easy switching between AMQP brokers.