If I’m not mistaken, EventStoreDB subscriptions using the gRPC client will open a dedicated bidirectional channel between the client and EventStoreDB and start consuming events from the given position in a catch-up manner.
What’s the best approach to deal with scenarios where the services that subscribes to EventStoreDB
$all streams, transforms and projects information in a “query side” database, scale horizontally?
In other words, If I have a client app that uses gRPC to subscribe to all streams, and discriminates events to only handle the interesting ones, what happens if that client app scales and suddenly I have two instances accessing the same streams and events in a duplicate manner?
Ideally they should compete, but since this is not a message broker but an event stream that can be read independently, do we have options other than these?:
- Ensuring there is just one client app, at all times, subscribed and creating projections or fanning out events to a shared queue.
- Ensuring multiple instances behave in an idempotent way, so the slower app won’t write what has already been written (although it will read the event from the stream again and “waste” resources).
PS: I’m interested in
$all streams since my streams naming follows a
AggregateName-Guid pattern and I don’t know the stream names in advance in order to subscribe to all of them, and that wouldn’t be practical.