These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
only writing to the corresponding message broker topics/queues (like Kafka) wich allows a Publish/Subscribe model between the microservices that want to read events and that wich publish events.
A local or replicated event log in Eventuate is actually an event bus that allows event-sourced actors (incl. views, writers and processors) to exchange events via a publish-subscribe model (see also event collaboration and event-routing). You can see event-sourced actors as stateful, event-sourced microservices that exchange events via an Eventuate event bus. There is no need to have a separate broker for exchanging events between event-sourced actors. An Eventuate application can setup several replicated event buses to model application-specific topics, for example. Different buses can be connected by
event-sourced processors if needed
An event bus is persistent so that event-sourcing is possible i.e. events can be replayed. An event bus can be replicated/distributed up to global scale and remains writeable even under network partitions (chooses AP of CAP). The strongest form of consistency under these conditions is causal consistency i.e. a replicated event bus guarantees causal delivery of events at any location (for more information see vector clocks) and repeatable delivery order at a given location.
If you still need integration with an external message broker, you could use event-sourced writers to transfer events from an Eventuate event bus to that broker (or an adapter to implement a bi-directional bridge). We're also thinking about a Kafka storage backend (see also #59 and #206) for the event bus, in addition to the existing Cassandra storage backend
and LevelDB storage backend.
My first question, What is the use case of EventsourcedViews? I think that EventsourcedWriters should be used always instead but without any projection logic
The use case for event-sourced views is to generate in-memory read models, that of event-sourced writers is to generate persistent read models. Concrete views and writers should actually implement projection logic. A special, degenerate form of projection logic is to transfer events from an Eventuate event bus to an external broker, as already mentioned, but that's not their primary use case.
If we use EventsourcedViews or EventsourcedWriters with logic aren't we coupling C and Q sides?
No, for implementing C of CQRS event-sourced actors should be used. They usually maintain an in-memory write-model as internal state. For implementing Q of CQRS, event-sourced views and writers should be used. Events are (asynchronously) transferred from C-side to Q-side via the event bus.
Hope that helps!