These are chat archives for RBMHTechnology/eventuate

7th
Jan 2017
Martin Krasser
@krasserm
Jan 07 2017 11:46

@magro processing events from only co-located EAs (determined by processId) sounds reasonable to me. To solve the problem of avoiding duplicate processing in fail-over scenarios, locations would need to agree on a processing leader which a consensus problem and therefore not compatible with the availability requirements of Eventuate locations. Consequently, processing fail-over to another location may lead to at-least once processing. You have two options to deal with it:

  • No processing failover: if a location crashes, processing of events that have been previously emitted at that location is delayed until the location recovers (and automatically resumes processing). In the meantime, the client could choose another location and continue emitting new events that trigger new processings.
  • Processing failover in combination with idempotent processing: the application needs to ensure that processing is idempotent. Idempotent in this case means globally idempotent (as local processing is already idempotent). For example, in case of payment transactions, a target payment service used by all locations needs to be able to detect duplicates.

On the other hand, data center outages should be a rare event so that the first option should be acceptable for most applications. Furthermore, within a data center there should be a HA leader-follower setup (ideally per local event log) where the leader is the node that writes to the event log. This comparable to a Kafka cluster where each topic partition has a leader (see also http://rbmhtechnology.github.io/eventuate/faq.html#how-can-apache-kafka-be-integrated-with-eventuate). This should give applications sufficient HA within a data center (i.e. location). Hope that helps!

Martin Grotzke
@magro
Jan 07 2017 22:39
@krasserm thanks, makes sense!