Skip to content

RabbitMQ — Trivia & Interesting Facts

Surprising, historical, and little-known facts about RabbitMQ.


RabbitMQ is written in Erlang, a language designed for telephone switches

RabbitMQ was built in Erlang, a language created by Ericsson in 1986 for programming telephone exchanges. Erlang's lightweight process model (millions of concurrent processes), built-in distribution, and "let it crash" philosophy made it ideal for a message broker. However, Erlang's relative obscurity has made it harder for the broader community to contribute to RabbitMQ's codebase.


The AMQP protocol behind RabbitMQ was created by JPMorgan Chase

The Advanced Message Queuing Protocol (AMQP) was initiated in 2003 by John O'Hara at JPMorgan Chase. The bank was tired of paying millions in licensing fees for proprietary message brokers like IBM MQ and TIBCO. AMQP became an open standard, and RabbitMQ (created by Rabbit Technologies in 2007) was the first widely adopted open-source implementation.


RabbitMQ's exchange-binding-queue model was inspired by email routing

AMQP's routing model — messages go to exchanges, which route them to queues via bindings — was inspired by SMTP email routing. The "topic exchange" works almost exactly like email routing rules, where a routing key like order.us.paid can be matched by patterns like order.*.paid or order.#. This design made RabbitMQ intuitive for developers familiar with email systems.


A single RabbitMQ node can handle over 1 million messages per second

With small message payloads and favorable conditions (persistent=false, no confirms), a single RabbitMQ node has been benchmarked at over 1 million messages per second. However, with durable messages and publisher confirms enabled (the production-safe configuration), throughput typically drops to 20,000-50,000 messages per second — a 20-50x reduction that surprises many benchmarkers.


RabbitMQ's memory alarm can silently block all producers

When RabbitMQ's memory usage exceeds the high watermark (default 40% of system RAM), it triggers a memory alarm that blocks all publishing connections. The broker remains running and consumers can still drain queues, but no new messages are accepted. This back-pressure mechanism has caused production incidents when teams did not monitor memory usage or understand the alarm behavior.


Mirrored queues were deprecated after 11 years of operational pain

RabbitMQ's "mirrored queues" (HA queues) were introduced in version 2.6 (2011) as the primary high-availability mechanism. They were plagued by synchronization problems — when a mirror fell behind and needed to resync, the entire queue would become unavailable. After years of operational complaints, mirrored queues were deprecated in 3.13 (2024) in favor of Quorum Queues, which use a Raft consensus protocol.


The Erlang VM's garbage collector makes RabbitMQ latency spikes predictable

Erlang uses per-process garbage collection with very short pause times (microseconds, not milliseconds). This means RabbitMQ does not suffer from the stop-the-world GC pauses that plague Java-based message brokers. However, Erlang's single-threaded-per-process model means individual queues can become bottlenecks if one queue receives disproportionate traffic.


RabbitMQ was acquired by VMware, then Pivotal, then VMware again, then Broadcom

RabbitMQ's corporate ownership has been remarkably turbulent. Rabbit Technologies was acquired by SpringSource (2010), which was acquired by VMware (2010), which spun off Pivotal (2013), which was re-acquired by VMware (2019), which was acquired by Broadcom (2023). Despite four corporate transfers, the core development team remained remarkably stable throughout.


Dead letter exchanges were added because messages need a place to die gracefully

RabbitMQ's Dead Letter Exchange (DLX) feature routes messages that are rejected, expired, or exceed queue length limits to a designated exchange for inspection. Before DLX was added in version 2.8 (2012), poisonous messages (messages that crash consumers) would cycle endlessly between the queue and failing consumers, a pattern called "poison message loops."