I have a backend system (A) that receives an HTTP request and sends a message to another backend system (B) through RabbitMQ before responding. But now, I need A to receive a response object from B.
I read up and found the RabbitMQ RPC system which allows me to send a callback queue for B to respond to. So my idea for the flow is that: A receives the HTTP request, creates a new short-lived queue, messages B (with the new queue as the callback queue), waits for the response from B on that queue, receives the response and then responds to the HTTP client.
What do you think of this process? Is it scalable? Are there any prominent performance challenges? etc...
Sébastien Portebois
Software architect at Ubisoft
From a number of queues standpoint, there's no risk, and it's one of the shiny features of RabbitMQ!
The only caveat is around the accumulation of pending messages, if/when the answers are not consumed (but that's not specific to RPC patterns, nor even to RabbitMQ, but a thing you have to deal with in any pub/sub systems: unread messages accumulating, and dead-letters). This is just a reminder to set TTL policies ;-)
I highly recommend you the 'RabbitMQ in depth' from Manning. As for as I know, it's the best resource you could find about RabbitMQ, and has a complete chapter on performance (chap 4), scaling (chap 7), and also RPC samples using the
message-idandcorrelation-idbuilt-in properties (Chap 6.1)The whole book is worth the read if you're using RabbitMQ. But with Manning livebook's tokens, you can also just unlock a few paragraphs for a few tokens (with the first 500 ones you got with an account, you might read those part for free)
The book homepage: manning.com/books/rabbitmq-in-depth