These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
The concept of location is entirely for allow sharding and horizontal scalability of the stateful actors?
No, not sharding but replication and availability (AP of CAP). Conflicting updates are allowed, with options to resolve conflicts later (automated or interactive).
A replicated event log only makes sense when I want replicated EventsourcedActors (actors with same aggregateId in different locations)?
A real production deployment would have 1 location per node (i.e. per jvm). It doesn't make sense more than 1 location per node, doesn't?
Locations are availability zones, so the most frequent use case is to have a location per data center (and event-sourced actor singletons within a location). On the other hand, RBMHTechnology/eventuate#143 will have a location per node, for example. It really depends on the use case, especially at which granularity you want to achieve availability during network partitions.
What are the relations between the event log and a Cassandra cluster? Is there a direct relation between the AP capabilities of each one?
Eventuate read/writes to a Cassandra cluster with strong consistency (QUORUM reads/writes).