Hey there @timob … just a follow-up: I heard of some reasoning for maybe why one might want to use a single large “catch-all” queue with Selectors, rather than individual queues per store. Cost! haha that’s a pretty good reason. Especially when looking to use Solace Cloud, and how large a service you might need for that.
By far, the better architectural approach would be to have each store have it’s own queue for receiving data… that way each store’s persistent data is decoupled and separate from other stores, you can control per-queue capacity, you can get metrics (msg rates and sizes per queue) etc. But if your rates are quite low across all your store (like in the 10s or 100s of messages per second) then the one-queue-with-Selectors approach could work well. But if the number of messages starts to go up, load goes up, you’ll probably need to start considering multiple queues in the future.
I’m just saying… the queue-per-store approach is definitely best, but there are many ways to slice a pie / skin a cat / do something with similar results… the Selector approach might be ok with careful consideration. Heck, maybe even one-queue-per-metro might be ok? Some hibrid where you have some separation, and some sharing. Anyhow, just putting some ideas out there.
Hope that helps…!