Current rpc model uses direct exchanges for rpc.call replies, and this results in too many direct "reply_<uuid>" exchanges and this makes rabbitmq maintenance as well as message tracing difficult. In the attached rabbitmq report, there are 25136 exchanges in total, of which 25071 are "reply_" exchanges. For reference there are only 30481 queues.
It would be easier if topic consumer directly publish reply to the control exchange with routing key simply be "reply.<uuid>" or even with more keys in there. Also, if topic publisher only subscribe to "reply.*" from a handful of control exchanges instead of every "reply_<uuid>" exchanges, there will be much less bindings for rabbitmq. Not only easier to maintain, but less chance for binding churns when service goes down and back up again.
Current rpc model uses direct exchanges for rpc.call replies, and this results in too many direct "reply_<uuid>" exchanges and this makes rabbitmq maintenance as well as message tracing difficult. In the attached rabbitmq report, there are 25136 exchanges in total, of which 25071 are "reply_" exchanges. For reference there are only 30481 queues.
It would be easier if topic consumer directly publish reply to the control exchange with routing key simply be "reply.<uuid>" or even with more keys in there. Also, if topic publisher only subscribe to "reply.*" from a handful of control exchanges instead of every "reply_<uuid>" exchanges, there will be much less bindings for rabbitmq. Not only easier to maintain, but less chance for binding churns when service goes down and back up again.
+---------+ +----------+ key: topic +-------+ +--------+ ------- ------- ------- >| control |<===========| | | | |----->| topic | ------- ------- ------- |consumer|
| topic |------
| | +-------+ | | +-------+ | |
|publisher|<----| | | | |=============>| exchange |<-----
+---------+ +-------+ key: reply.* +----------+ +--------+