artsy / atomic-store Goto Github PK

For efficiency, we should serialize atomic store messages to protobuf.

It may be possible to simplify this project further. Today, the EventLog actor replies to its sender for validation, but it seems like this may be unnecessary.

Naive case
Assuming the validator is static, the atomic store could be instantiated with the validator of a type such as (CurrentEvent, PastEvents) => ValidationResult. If this were the case, the EventLog could make its persistence decisions without needing to make any external communication, because the decision logic would be injected at startup time.

Plus async
That assumes that validation can be done synchronously. More generally, the type would be more like (CurrentEvent, PastEvents) => Future[ValidationResult]. In this case, the stateful stashing behavior of the EventLog would still need to be retained, in order to guarantee atomicity of validation+persistence.

Plus auxiliary input data
It may be desirable to have some data taken into account for validation, yet a different representation actually persisted as an event. For example, in canonical Event Sourcing, commands are requests to change state, and events are a record of what happened. Perhaps it would be more general to define the interface as (Command, PastEvents) => Future[Seq[Event]]. This generalizes over the concept of auxiliary input data.

Plus auxiliary output data
The validation process has knowledge of the change in state effected by a command. It may be desirable to propagate some information out about the validation process (e.g. errors) or the resulting changes. So perhaps the most general validator interface would be (Command, PastEvents) => Future[(Seq[Event], AdditionalData)].

Side objective: Split out atomicity
But it occurs to me that this behavior atomic processing of incoming commands is actually independent of the storage concern. Could this behavior be factored into a mixin or wrapper-actor? If so, the actual persistence part could potentially be written basically the same as in the naive case. With care for handing buffering, this could be a very generic way to allow actors to cope with async APIs in a way that also preserves the actor framework rule of sequential message processing.

It occurs to me that this sounds a lot like a Reactive Stream with a capacity of 1 before backpressuring. I think this may be a red herring though, because the actor would still need to be a Cluster Singleton (for atomicity) and accessible via Remoting, neither of which fit the Akka Streams model.

Requester might be an example to look at for how to make such behavior modular, although it isn't designed to be atomic.

See also Fun.CQRS for an attempt to model the pattern in types.

For reliability, performance, and failover, Atomic Store should be deployable to a cluster. The individual EventLog actors should be cluster singletons.