These are chat archives for RBMHTechnology/eventuate

19th
Apr 2016
Martin Krasser
@krasserm
Apr 19 2016 10:32

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)?

No, see also event collaboration (and event routing).

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).

Martin Grotzke
@magro
Apr 19 2016 12:48
Re "the relations between the event log and a Cassandra cluster" I'd say that usually you'd have 1 cassandra cluster per location, using eventuate's event replication for crossing DCs/locations.