These are chat archives for RBMHTechnology/eventuate

17th
Feb 2017
Volker Stampa
@volkerstampa
Feb 17 2017 14:05

Currently Eventuate allows for each location to define its replication connections to other locations at start time and for redefinition the actor system has to be restarted. A replication connection defined at location A to location B replicates (unidirectional) events from B to A. If there are replication connections in both directions they form a bidirectional replication connection. All connected locations with their replication connections from the replication network.

For your example it could make sense to build a replication network, where

  • each producer is a location and writes in its local event log
  • each consumer is a location
  • the consumers are connected to each other through bidirectional replication connections (any setup between sparse and totally dense is valid)
  • each producer is connected to n consumers through replication connections defined at the consumer side (replicating events from producer to consumer)
  • to allow disaster recovery of producers the replication connections between consumers and producers need to be bidirectional. To avoid that events from producer A get replicated over consumers to producer B the replication connection defined at the producer to consumer should be filtered and let only those events pass that originate from this producer.

With this setup all consumers get all events from all producers while producers only see the events they emitted themselves. Even though this replication network introduces cycles over filtered connections (which is currently not supported in the general case) it is a valid setup as producers see only their own events.

HTH

gabrielgiussi
@gabrielgiussi
Feb 17 2017 14:44
@volkerstampa Can we achieve the same with EventsourcedActors with aggregateID as Producers and EventsourcedViews without aggregateID as Consumers, handling only specific types of events generated by producers?