These are chat archives for RBMHTechnology/eventuate

30th
Aug 2015
Martin Krasser
@krasserm
Aug 30 2015 06:21

In Eventuate, you can use conditional requests to delay commands or queries until updates have been propagated to replicas. With conditional requests you achieve read-your-write consistency across replicas.

In your example, a payment processor could query replicas if they have converged to selecting a user for a given reservation. Should some replicas be unavailable for reading, payment must be retried later. This shouldn't be a problem as payments can be executed in the background.

With this approach you choose to prevent invalid payments at the cost of limited availability during network partitions. On the other hand, should the business rules allow some wrong payments (in case of conflicting reservations) with automated compensations, all decisions could be made locally which might be an advantage during long-lasting network partitions.

There are some more options how to deal with reservations in a highly-available eventually consistent system, see Pet Helland's excellent paper Building on Quicksand, section 7.1 Over-Booking vs. Over-Provisioning.

In general, if you want to prevent a conflict in a multi-master system, this can only be done at the cost of availability. If decreased availability is not an option, you have to allow conflicts (and wrong decisions) and compensate (or apologize) later. You can use both strategies in the same application, choosing the more appropriate one per action.

Magnus Andersson
@magnusart
Aug 30 2015 09:36
Great thanks for the link to the paper, will give it a read. The conditional request looks promising and I get your reasoning about availability will suffer with strong consistency. In one way it would boil down to economy. How much would it cost me to compensate an unlucky user given it will happen to x users each month.
Magnus Andersson
@magnusart
Aug 30 2015 17:51
I’m currently reevaluating LevelDB with Cassandra clustering. With Akka Persistence the obvious advantage with Cassandra was the replication, but with Eventuate that is already built in. The only advantage I can come up with Cassandra in the Eventuate scenario would be separation of data storage management and application management. Perhaps the tooling is a bit better as well. Are there other compelling reasons for using Cassandra instead of LevelDB?
Konrad `ktoso` Malawski
@ktoso
Aug 30 2015 17:52
writing any kind of query to leveldb is a huge pain ;)
i.e. if at some point you'll want to query something complex than recover actors (i.e. by persistence id)
Magnus Andersson
@magnusart
Aug 30 2015 17:53
@ktoso Yes I considered that. But the data is serialized so what useful queries can you do?
Konrad `ktoso` Malawski
@ktoso
Aug 30 2015 17:53
to build some projection ("materialized view") faster for example etc
Magnus Andersson
@magnusart
Aug 30 2015 17:54
Ah… right.
So I would customize what produces the event stream for a view for example?
Konrad `ktoso` Malawski
@ktoso
Aug 30 2015 17:54
I wouldn't really recommend using leveldb in prod... we've seen it have very long compaction times
(during which it does not respond to anything)
Magnus Andersson
@magnusart
Aug 30 2015 17:54
Oh
Konrad `ktoso` Malawski
@ktoso
Aug 30 2015 17:55
we ship it in order to have a simple journal as "demo"
(for persistence)
maybe less of these (query) things apply to eventuate, but i'd still pick a distributed journal
Magnus Andersson
@magnusart
Aug 30 2015 17:56
Right, I was still leaning towards Cassandra and it seems I should continue on that track. But I like to have motivations for each components clear. :)
Is there an extension point in the cassandra event journal where I can customize how queries are made to the event log? Or would I need to write my own
Konrad `ktoso` Malawski
@ktoso
Aug 30 2015 17:59
if you're asking about eventuate then that I don't know :) Martin will have to chime in
Magnus Andersson
@magnusart
Aug 30 2015 17:59
Alright, I think I’ve asked something similar before actually. It was a feature not yet implemented.