Why is there no reply_to_exchange?

[ehaynes99]

In general, consumers deal with queues, and producers deal with exchanges. The entire concept of "send a message to a queue" is actually "send a message to the default exchange with a routing key of the queue name". When using RPC style with reply_to, in effect, you have both a producer and a consumer... sometimes.

If you want the current process to handle the response, then you do, in fact, have both, so using typical consumer patterns is in order. However, if you want to handle the response in a completely asynchronous manner where PartyA sends a message to PartyB and wants the response to go to PartyC, PartyA is merely a producer, but required to know a specific queue name that will get to PartyC. In this case, it seems like it would make a lot of sense to allow something like reply_to_exchange: 'some-fanout-exchange' or reply_to_exchange: 'some-direct-exchange:some-routing-key'.

[michaelklishin]

@ehaynes99 Direct Reply To had one very specific goal in mind: avoiding a one-off temporary queue declaration for each and every response. That's a very expensive operations for request-reply systems with a high throughput rate.

You can build what you want without Direct Reply-to, and use exchanges or even exchange-to-exchange bindings.

[ehaynes99]

To be clear, when you say "build what you want without Direct Reply-to", you mean include the destination in the payload and explicitly send the response in the consumer?

[michaelklishin]

Yes, that's how request-response worked before Direct Reply-to. The client includes the information the server would need to send a response. An exchange name and a routing key, a correlation ID, that kind of thing.