RabbitMQ

RabbitMQ is an open-source message-broker software written in Erlang and built on the Open Telecom Platform. It enables efficient, reliable, and versatile communication for distributed applications through multiple messaging patterns.

Key features

• Multi-Protocol Support: Native AMQP 0-9-1 and AMQP 1.0, plus MQTT 5.0 and STOMP via plugins
• Flexible Routing: Direct, topic, headers, and fanout exchanges for sophisticated message routing
• High Availability: Clustering, mirrored queues, and quorum queues for fault tolerance
• Streaming: Built-in stream support for high-throughput, persistent messaging
• Management UI: Web-based management interface for monitoring and control
• Plugin Architecture: Extensible via plugins for federation, shovels, and protocol adapters

Queue types

• Classic Queues: Traditional message queues with optional mirroring
• Quorum Queues: Modern replicated queues based on Raft consensus
• Streams: Append-only logs for high-throughput, replayable messaging

Deployment options

• Docker: Official images with management plugin
• Kubernetes: Operators for cluster and topology management
• Package Managers: Apt, DNF, Homebrew, Chocolatey
• Cloud: Amazon MQ, VMware Tanzu, self-hosted on EC2
• Binary: Direct download for Windows, Linux, macOS

Use cases in manufacturing

• Microservices Communication: Decouple services in Industry 4.0 architectures
• IoT Data Ingestion: Handle millions of device connections with MQTT
• Event Streaming: Real-time data pipelines for analytics
• Work Distribution: Task queuing for batch processing and job scheduling
• RPC: Request/reply patterns for service coordination

Integration ecosystem

RabbitMQ integrates with virtually all programming languages and frameworks. Client libraries are available for Python, Java, JavaScript/Node.js, Go, C#, Ruby, PHP, and more.

Limitations

• Erlang runtime is less common than Java/Go, making custom plugin development harder for most teams
• Lower throughput than Kafka for pure streaming workloads (tens of thousands vs millions of messages/sec)
• Mirrored queues are deprecated in favor of quorum queues — migration required for older deployments
• No native event replay capability — consumed messages are gone (unlike Kafka's log retention)
• Management UI provides monitoring but not full operational control (no partition rebalancing equivalent)