These are chat archives for RBMHTechnology/eventuate

13th
Dec 2015
Martin Krasser
@krasserm
Dec 13 2015 08:08
@lujimmy you can do that independent of the storage backend with an EventsourcedWriter (see also this architectural overview). When a writer is started it automatically subscribes to changes in an event log. You can find further details in the API docs. Not sure if I understood your question regarding atomicity. Eventuate batch-writes event atomically to the storage backend(s). These writes are idempotent and the storage order is consistent with causal event order (see this section in the docs). So, consumers (including EventsourcedWriters) see a de-duplicated, causally-ordered event stream when reading from the log.
Jimmy Lu
@songyunlu
Dec 13 2015 10:15
@krasserm thanks for the reply, I think I missunderstood how event sourcing is actually work compared to the mechanism of traditional event-drivent application described here: Event-Driven Data Management for Microservices. One additiaonal question is, does EventsourcedWriter reads event logs periodically from the storage backend? Because it seems that there is no CDC (change data capture) support in Cassandra now.
Martin Krasser
@krasserm
Dec 13 2015 12:17
@lujimmy having read the article, I do now understand your atomicity question. Eventuate uses the event-sourcing to achieve that atomicity, as explained in the article. Eventuate also implements an event bus on top of the event logs so that different event-sourced actors, views, writers, ... can consume each other's events. You can also think of event-sourced actors as microservices that can collaborate via events, like the services in the article. Furthermore, the event stream consumed by these actors is causally ordered i.e. with Eventuate you can achieve causal consistency in addition to plain eventual consistency (which doesn't say anything about event order).
Jimmy Lu
@songyunlu
Dec 13 2015 12:21
Got it! Thank you so much for the explanation!
Martin Krasser
@krasserm
Dec 13 2015 12:24

does EventsourcedWriter reads event logs periodically from the storage backend?

Eventuate pushes events to event-sourced writers/actors/views/... after having successfully written them at a location or replicated from other locations i.e. these actors consume events with minimal latency. This is independent of the chosen storage backend.

You're welcome @lujimmy :smiley:
Jimmy Lu
@songyunlu
Dec 13 2015 14:00
Hi @krasserm just came out another question: what if there is failure on updating query stores by EventsourcedWriter that leads inconsistent data between event log and query stores, is there any best practice to handle the situation?
Martin Krasser
@krasserm
Dec 13 2015 16:02
@lujimmy you can consider the example in event-sourced writers as one of several possible examples how to handle failures. When the writer fails to write to the query store, it restarts itself and resumes event processing from the last stored sequence number + 1. The last stored sequence number (= write progress) is read by the writer from the query store during (re)start, before any further writes are made. If the progress is written atomically with the actual data, idempotency can be implemented on writer-level, otherwise, query store updates themselves must be idempotent. Failure recovery and idempotency is also covered at the bottom of the event-sourced writers section.
Jimmy Lu
@songyunlu
Dec 13 2015 16:06
really cool! I’ll take a look and give it a try. thanks again @krasserm :smile: