What do you feel is a reasonable approach for an EventHandler to have state?
For example, one EventHandler is responsible for “broadcasting” an event to all “subscribers”. As there could be thousands of subscribers and a rapid succession of broadcasts, I would rather not copy the subscriber list and attach it to each “broadcast” event (then having it stored in the EventStore). Similarly, I don’t feel that having the AR applying a “SentToSubscriber” event per subscriber is efficient.
Most clever ideas I’ve come up with fall over if the server is restarted after an Event is committed to the EventStore but before it is successfully handled by all EventHandlers. Is this basically where Sagas come into play?
(For performance reasons, I’m using the DisruptorCommandBus and the AsynchronousCluster.)
in general, event handlers store their state in a persistent view model. In some cases, they simply update it based on events, in other cases, they keep some state they need to query before being able to update.
Whether or not sagas would help in your case is something that depends on the details. An advantage is that it's relatively easy to keep track of subscriptions and to store state. Sometimes, the exact same can be achieved using a simple event listeners that stores its state somewhere.
About the server restart issue, that's mainly due to the asynchronous cluster. It simply does not guarantee an event is ever processed in case of a server crash. If you want that, you should consider using persistent queueing technology. The AMQP terminal on a clustering event bus could help. You could also use a persistent queue implementation that uses an append-only file (there are some around) to ensure that the state of the queue is recovered after a restart.