I'm currently planning an architecture for a system that should consist of multiple microservices. We definitely want to make use of a message broker (probably RabbitMQ).

A simplified diagram of my current approach looks like this:

enter image description here

As you can see in the diagram I added a Response Queue, which is used by the services to send their responses back to the REST Server.

For some reason I have a bad feeling about exposing the message broker to the frontend. That's why I'm planning to combine the access to the different exchanges in a single REST API instead of having the clients to communicate directly with the message broker.

I would then have a mapping like this:

REST                     Exchange            Routing Key
DELETE /users/{id}       UsersExchange       cmd.delete
POST   /users            UsersExchange       cmd.create 

So my first question is: Is that a common way of working with a message broker or is it better to address it directly from my client applications?

And my second question: How would I handle a GET request? If I follow the pattern above, I should use the following mapping:

REST                     Exchange            Routing Key
GET /users              UsersExchange       cmd.get

I just put a JSON with all users into the payload of my response message. So far, so good. But in some talk about RabbitMQ they said that you should keep your messages as lightweight as possible. I wonder what "lightweight" means in this context. Are we talking about a Kilobyte? Megabyte? ...? Is there even any alternative? As soon as my REST server addresses the database or one of the services (e.g. via http) directly, I loose any advantage of the message broker.

3 Answers 3


Actually, in the most common scenarios*, not only brokers are hidden behind a REST API façade, but there is no direct mapping with APIs. Messages are not used to perform query or "commands", they are just a way to notify events, things already happened in some microservice that could trigger reactions in other microservices, unless you need to build workers that execute async taks. The only reason you would need to map a GET HTTP request to a message is that the query performed is very long running and you can afford to deliver results asynchronously, otherwise you don't receive any benefit on using messages

In this case though, from a pure design perspective, I would not map this query as a GET, having something like a POST /search would indentify better the fact that we are talking about a real long running task

*not real time distributed applications, which often use some bridging bewtween AMQP broker and other technologies like MQTT, websockets, ZeroMQ


You are right about not exposing clients directly to the message bus as you have to implement authentication, rate limiting and probably others things that the message bus does not provide.

Keep the messages small as possible as there is a huge latency degradation with large messages. Big is ~ >1mb and small is <1kb.

I would recommend that you do benchmarks by your self and test which size is acceptable for you.

Also consider using Protocol buffers instead of Json and think about if you really want to use AMQP and not NATS or kafka.


I think its always a better idea to return the reply to the service that sent the request.

In your case UsersExchange and SomeOtherExchange would each manage a reply queue.

Appart form aesthetics there are a couple of good reasons for doing this.

Session state -- you may need to tie up the replies with the original request in order to root it to the correct client -- this is easier if the process picking up the reply is the same one that sent the request.

Scaleability -- the single reply queue could become a bottleneck, if the queue is attached to the Exchange server then you could scale out running more Exchange servers each with its own reply queue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.