If you currently use multiple subscriptions on the same subscription either on the same stream or on $all could you let me know?
Why I want to know continues …
I would use multiple subscriptions to $all when either aggregating events in multiple streams to a common read model (Search or Reporting for example) which needs to be in order. I would have dozens of microservices that would integrate via EventStore and while using category projections works for the most part, we might have multiple category streams which have multiple subscriptions in multiple bounded contexts. As we have been avoiding using custom projections to subscribe to multiple streams, we usually subscribe to $all when we need ordering across the various categories.
Any optimizations around this would be welcome, but we would want to avoid processing events out of order so a pause is OK if we get a general uplift in performance, we only generally allow that where something like a process manager, which again is handled by pushing events to a servicebus from the $all stream. My biggest worry about subscribing to $all is the amount of events skipped on the client, as we have a mixture of Aggregate Events and Integration Events (snapshots from non EventSourced systems) from other bounded contexts mixed in.
What are your latency requirements in general and how does inevitable failure impact latency requirements? Over UDP there will obviously be cases where a packet is missed etc.
It varys, but in sensitive areas (user carts etc) I could revert to a TCP.
A lot of the $all subs use a Reactive Buffer which has a wait of about 5-10 seconds or n messages before processing a batch, and some are overnight jobs so a couple of minutes to an hour in those cases so there is some leeway.