Best practice on POSTing directly to the default exchange

[Praveen Chandhar Nageswaran]

Hi team!

Beginner here.

I want to use RabbitMQ for an event based architecture service I am developing. My question may sound silly, please bear with me.

Lets call my service A.

So, some other service (service B) would send a cloud event to my service. My service would then act as a publisher and put it in a queue. This queue is purely for my service, with persistence. I will then consume the message in the queue at my own pace

I am worried about what will happen when my service is down when service B sends the cloud event. We can assume that my queue will be up, but not my service.

In such a case, service B would not be able to send the event itself, as A is down.

One solution I thought off was B can post directly to the exchange instead of to A. This way, even if A goes down, it can process the messages whenever it is up.

Is POSTing directly to the exchange a recommended way for production systems?

I discovered a way in Stack Overflow, but having second thoughts as I read somewhere that it is used mostly for debugging.

[Mirah Gary]

You have the right idea that you should use RabbitMQ to act as the intermediary to avoid the need for synchronous interactions between B and A. However, as you have noticed, using HTTP to POST directly to the exchange is intended only for testing purposes and is discouraged for production use-cases. I would recommend looking into updating your application B to make use of an AMQP (or other messaging protocol) via a client library. If that is not possible, you can consider using an intermediary application C that acts as a proxy and converts HTTP into messages published to RabbitMQ via a long-lived connection, something along the lines of AMQProxy https://github.com/cloudamqp/amqproxy but with the added conversion step. 

Best,