An introduction to RabbitMQ
I&#x27;ve been using rabbitmq heavily for a fairly large hobby project (20-100 messages&#x2F;sec) for a few years now. I&#x27;m generally happy with it, but there are a number of caveats I&#x27;ve learnt.<p>1. If you have large messages and use keepalives (and you&#x27;ll need keepalives), you need to write your own message fragmentation.<p>2. There are no python libs that just work. I&#x27;m currently using a vendored version of amqpstorm with a bunch of hacks to handle wedged connections. I have some AMQP connections that are intercontinental, and I&#x27;ve been able to wedge literally every other AMQP library.<p>3. If you have a single open connection, it <i>will</i> get stuck from time-to-time. With a bunch of both in-band and out-of-band keepalives, I&#x27;ve got it to the point where I don&#x27;t have things permanently block, but you should expect things getting stuff for ~2x your heartbeat time periodically. This doesn&#x27;t seem to result in message loss. I&#x27;ve dealt with this by just running LOTS of concurrent connections, and aggregating them client side. This has worked fine.<p>4. In general, exactly-once delivery isn&#x27;t a thing. You should design either for at-most-once, or at-least-once delivery modes exclusively. Idempotency is your friend.<p>5. The tooling &#x2F;around&#x2F; the rabbitmq server is a dumpsterfire.<p>Basically, I feel like the core server is super durable (note: I&#x27;m not running a cluster, so this doesn&#x27;t generalize to multi-instance cases), but the management stuff is god-awful. The main management CLI tool actually calls the HTTP interface, which is kind of ridiculous. I&#x27;ve occationally run into a situation where I wound up with leaking temporary exchanges, and just flushing bogus exchanges is super annoying.<p>I don&#x27;t think there&#x27;s any other options that can do what rabbitmq does for my use-case, but it&#x27;s had quite the learning curve.