1

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.

0

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.

0

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, privacy policy and cookie policy

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