RabbitMQ

lastmod 2025-12-24created 2016-06-2113 edits

RabbitMQ is the most widely deployed open source message broker.

With more than 35,000 production deployments of RabbitMQ world-wide at small startups and large enterprises, RabbitMQ is the most popular open source message broker.

Features

• Robust messaging for applications
• Easy to use
• Runs on all major operating systems
• Supports a huge number of developer platforms
• Open source and commercially supported

RabbitMQ implementation of an event bus

• Implementing an event bus with RabbitMQ for the development or test environment

See also

• Advanced Message Queuing Protocol (AMQP)
• ActiveMQ
• ZeroMQ
• Kafka
• MQTT
• Streaming Text Oriented Messaging Protocol (STOMP)
• Durable Streams - open protocol for real-time sync for client applications

Favorite site

• RabbitMQ web site
• Building an asynchronous data processing system with RabbitMQ
• Modern Message Queue (Messgae Queue) MQ technology - about the modern message queues (Messgae Queue) MQ used in Java
• [Recommended] (node.js) Sending and receiving messages with rabbitMQ (Node.js)

Article

• SQL Maxis: Why we replaced RabbitMQ with a Postgres Queue
  • Ripped out RabbitMQ and replaced it with an SQL-based queue in PostgresDB
  • The replacement took about half a day, and the source shrank by 580 lines
  • Far more important: stability and resiliency improved greatly
  • Not a story about problems with queue systems like RabbitMQ, but part of an effort to keep things simple
    • Prequel, the author of this post, is a product that helps B2B SaaS companies sync with their customers' DBs via large-scale data pipelines
  • Built with RabbitMQ + AQMP + Helm + a GoLang wrapper; it worked well for a while, but problems started to appear
    • Message delivery was delayed so long that messages got cancelled
    • Consumers prefetched messages, holding on to the next message until the current one was done
    • Setting prefetch to 0 means unlimited, so disabling prefetch was impossible
    • The problem arose because the jobs that receive and process messages are usually long-running (data transfers)
  • They figured out exactly what was happening, but had no way to fix it immediately. The problem hit production customers, so waiting was not an option
  • So they switched to reading and writing with a single simple table in Postgres
    • Read/write Row-Level Locks guarantee that only one consumer reads a job
    • Ridiculously simple, but working perfectly
  • Advantage: application state is unified in one place instead of being split between RabbitMQ and Postgres