Causal event delivery

[krasserm]

Storing events in an order that is consistent with their causal relationship can be inefficient. When giving up causal storage order, Eventuate must re-order events before delivering them in order to preserve causality on application-level.

Applications should also also be able to disable causal delivery. This is useful for actors that manage Counter or MV-Register CRDTs, for example, for which causal delivery order is not relevant. Other application-specific actors and/or views may also want to turn off causal delivery if their state update operations commute.

[krasserm]

An initial implementation (M1) exists on branch wip-66-causal-event-delivery. In this implementation, event-sourced actors and views re-order events before delivering them to their event handler. It is assumed that an actor that handles a given event also handles all causally related events. Hence, these causally related events

1. must pass all replication filters
2. must be routed to that actor and
3. must be handled by that actor

This is the case for some applications, such as Eventuate's operation-based CRDTs, for example. However, the above assumptions cannot be made in general because application-specific replication filters, routings and event handlers can prevent causally related events from being handled by a certain actor.

[krasserm]

Eventuate will continue storing events in causal order.