Hi
I was reviewing the runtime structure of nameko. I was wondering why did you decide to create one exchange per service for events?
For example, Couldn’t we have a single central exchange for all the events in the system?
Hey @MahdiZareie,
I don’t remember exactly why we did it this way. It seemed like the appropriate way to use RabbitMQ. We could have opted to use a single exchange for all events, just as we did for RPC. To be honest, it’s odd that is isn’t consistent.
Matt.
1 Like
Thanks Matt. I really appreciate your attention.
We had this discussion with our team to use a single exchange for all of our events in the system, making the runtime structure a little bit simpler. Since you’re an expert on this matter, can you think of any downside to this design? Scalability issues perhaps? although we don’t really expect more than 10k events per day on our good day.
I think the throughput is limited by the broker rather than the exchange. It’s a logical distinction only AFAIK. At those message rates it wouldn’t make any difference anyway.
The only downside I can think of is that you lose the ability to set options more granularly. Exchanges are not very configurable though, so there’s probably little value in that unless you have a particular use-case.
1 Like