When to update views that are used in async notifications?

Our system has the requirement to send async notifications (over web socket) to connected clients. These notifications typically contains View/Query data. My problem is that as you can’t make assumptions on which event listener is invoked first, the EventHandler who is responsible for denormailzing the event/updating the View model could be invoked (in theory much) later than the EventHandler who notifies the client. This results in pushing notifications with out-dated view/query data to the client. Prioritised events could somehow mitigate this, but I don’t know if this is possible and it feels like a workaround. A secondary event for XXXViewUpdated would cast a whole new layer of events on top of the domain events, so that sounds like a bad idea as well… Any idea how I could solve this with axon?

What you are describing is a long running process which is usually modeled as a Saga. The Saga could listen to all events and once it confirms that everything is in place it could raise an event (ProcessCompleted) to send the notification.

Thanks, for your reply. If I get you right would that mean that I’ve to emit events when the views are updated as well?

Hi Pepster

I have done something similar in one of my projects. We perform the update of the view model and send updates to the connected clients in the same event handler. Basically, the event handler updates a JSON document based on an incoming event. Then, we send a JsonDiff of the old vs the new state to the clien, so that they can update their local view of the document.

When multiple handlers rely on eachother state, they must be in the same cluster. Within a Cluster, you can force handlers to be invoked before others (see OrderResolver as constructor parameter in SimpleCluster).