EventStoreSubscription Limits?

EventStoreDB
1

I’m using subscriptions to keep some read-models up to date and I’m wondering which direction I should take.

  • Big Monolithic Model (shared across all views)
  • One subscription per stream
  • Higher network latency aspect.
  • Easy on the EventStore server.
  • Models per View
  • Lowest network latency potential.
  • Many subscriptions to a single stream.
  • More stress on the EventStore server?
    If this were just one stream at a time, I wouldn’t even bother asking the question. But, it’s entirely possible that, in the second case, we would end up with thousands of subscriptions.

Is there a recommended upper limit to the amount of subscriptions to one stream or to a connection in general? Or should I not worry about it?

Thanks,

Chris

2

The atom feed with varnish in front would handle a lot of clients.

3

I’m using the .net TCP client.

4

Greg has said that tousands works ok, but do a test. If you need more subscribers (millions varnish and http is the only solution)

5

Mostly do the number of connections... at this point you would scale
out nginx/varnish

6

I decided to forego many subs per stream in favor of a big akka.persistentview per stream that supports querying “screen” views.