These are chat archives for RBMHTechnology/eventuate

5th
Nov 2016
Martin Krasser
@krasserm
Nov 05 2016 08:02

all Spring nodes of course should see the same state / use the same data where state divergence should be avoided if possible

With divergence allowed I mean if temporary divergence should be allowed. Of course, replicated state should eventually converge. If you allow temporary divergence e.g. making potentially conflicting updates during partitions you need to resolve conflicts later. This is compatible with AP of CAP and where Eventuate fits in. A special application of automated conflict resolution are CRDTs. On the other hand, if you want to prevent temporary divergence of replicated state (so that you don't have to resolve conflict later), you need coordination which is not compatible with AP of CAP i.e. you sacrifice availability for stronger consistency of replicated state. If you want to achieve that, Eventuate is not what you want.

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

yes, that's possible for testing. Each Spring node should use its own keyspace in the shared Cassandra cluster then. Alternatively, you could also use a LevelDB storage backend at each location, making deployment even more lightweight.

Marco Ehrentreich
@mehrentreich
Nov 05 2016 15:14
@krasserm thank you very much for your answer
after rethinking the requirements for our application and considering the important points you mentioned I come to the conclusion that it probably would be a good idea to start small, gain some more experience and insights and scale as needed
nevertheless I think we will use Eventuate and just start with a single node deployment which gives as the chance to think about and implement everything needed for a distributed deployment with replicated state
Marco Ehrentreich
@mehrentreich
Nov 05 2016 15:19
of course we wouldn't benefit from the advantages Eventuate can offer at the beginning but it still is a very attractive solution to stick with CQRS and event sourcing
and from my understanding it should be possible to make use of the more advanced features later without having to throw away everything
do you think it is too naive to think that we can retrofit features for global scalability or high availability later if the application is already designed with CQRS, event sourcing and eventual consistency in mind?
Marco Ehrentreich
@mehrentreich
Nov 05 2016 15:25
of course there would be at least some work to be done, for example to make use of CRDTs to resolve conflicts
but I guess it shouldn't require a complete rewrite of the application
Martin Krasser
@krasserm
Nov 05 2016 15:35
@mehrentreich sounds absolutely reasonable. I know of several applications that use Eventuate for ES and CQRS without state replication (which is only one of several useful Eventuate features :wink:). Later scaling shouldn't be a big deal provided you know how to resolve conflicts. Glad to hear that you want to give Eventuate a try :smiley: