These are chat archives for RBMHTechnology/eventuate

4th
Nov 2016
Martin Krasser
@krasserm
Nov 04 2016 05:59

do have to configure and implement this as multiple locations with replication in between even if all nodes run in the same data center and use the same Cassandra cluster as storage engine?

See http://rbmhtechnology.github.io/eventuate/architecture.html#storage-backends

or is causal event order also guaranteed withouth if several instances of Eventuate are sharing the same Cassandra cluster?

in this case, you have event replication within a shared Cassandra cluster but with limited availability (because of QUORUM writes to the cluster) which contradicts the idea of locations as availability zones. Causal event ordering is given in any case.

Rather than discussing technical solutions first it would be interesting to know what your distributed/clustered application does, what consistency/availability requirements it has and how it should behave under failures (network partitions, ...).

  • Do you have replicated state or partitioned state?
  • In case of replicated state, is state divergence allowed or should be prevented?
  • Is it acceptable if the application is only partially or not available for writes during a partition?
  • ...
Marco Ehrentreich
@mehrentreich
Nov 04 2016 17:22
@krasserm the project in question has currently the status "pet project" but hopefully it will be ready for production use in the near future
it should serve as a kind of b2b trading platform for special goods
so in this sense it's something like a tiny ebay :-)
I'm well aware of the fact that that it may seem like much over-engineering but after all part of the project is also to learn new things and get experience with stuff I cannot use at work
but on the other hand it would be quite nice if the application would be a success and had scalability already built-in
Marco Ehrentreich
@mehrentreich
Nov 04 2016 17:28
at the moment most features involve user interaction but there are also features planned for the future which will need more backend work without users interaction
one of the main reason to deploy the application on multiple (probably virtual) nodes is for easier maintenance and to get some degree of high-availability
for a start we don't want to spend too much money and too much effort in operational work so the idea was to use a small single Cassandra cluster as our main storage and just replicate the Spring Boot application behind a load balancer
like described above the application was already designed for CQRS and event sourcing so it was surprisingly easy to replace our hand-rolled oversimplified event store implementation with Eventuate
even though the frontend part is still implemented in Groovy it works nicely together with the domain core and persistence implemented with Eventuate
Marco Ehrentreich
@mehrentreich
Nov 04 2016 17:34
that said the problem boils down to the question if Eventuate will work as expected if I have a running instance of Eventuate in multiple Spring application deployed on multiple nodes which share a single Cassandra backend
it's clear that the whole application is down if the single Cassandra cluster is down
but load-balancing the Spring application of course only makes sense if the other nodes are still functional when a Spring node goes down or there's a network partition which isolates a Spring node
Marco Ehrentreich
@mehrentreich
Nov 04 2016 17:40
additionally all Spring nodes of course should see the same state / use the same data where state divergence should be avoided if possible
but we are still able to change our plan if that's complete nonsene
thx for your help
Marco Ehrentreich
@mehrentreich
Nov 04 2016 17:49
the easiest solution would be if all Eventuate instances (in each Spring application) could access the same tables and keyspace
but I am completely unsure if this would be considered a local event log
I guess it's not that easy :-)