RabbitMQ

Use it when

• Routing is the problem: direct, topic, fanout, and header exchanges, dead-lettering, TTLs, and priorities express delivery logic a plain log cannot.
• Work distribution across competing consumers is the dominant pattern, with acknowledgements and redelivery built in.
• One broker should serve both queues and replayable history; Streams add the log access pattern inside the cluster you already run.
• Protocol breadth matters: AMQP at the core, MQTT and STOMP via plugins.

Think twice when

• The workload is a high-throughput analytics pipeline; partitioned logs like Kafka or Redpanda are built for that shape, and RabbitMQ is not.
• You need geo-replication as a first-class feature; Federation and Shovel bridge WANs, but clustering itself wants a reliable LAN.
• Nobody wants to own Erlang operations; nodes need matching versions and the runtime is its own discipline.

How it runs

Self-hosted as an Erlang/OTP cluster, with quorum queues and streams replicated across nodes and messages on local disk. Scale by adding nodes and placing queues. No connector ecosystem; exchanges route rather than transform. Managed RabbitMQ is available from several providers, including CloudAMQP.