Message Broker in Client-Server-Applications

distributed-systemmessage-queuemessagingmicroservicessoa

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.

Best Answer

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.

Related Topic