These are chat archives for RBMHTechnology/eventuate

8th
Mar 2017
Martin Krasser
@krasserm
Mar 08 2017 06:38
@joshlreese Yes, exactly. That's comparable to PerisistentActors and their journal actor in Akka Persistence.
Josh Reese
@joshlreese
Mar 08 2017 12:57
@krasserm Ok, that makes sense too, thanks for confirming. So - for the case of write scale-out, I'd likely need to shard the local logs (via application logic), and for the read side, aggregate from each of those.
Martin Krasser
@krasserm
Mar 08 2017 13:00
@joshlreese Exactly. Aggregation can be done with uni-directional replication connections from the shards to the aggregate log, for example.
Josh Reese
@joshlreese
Mar 08 2017 13:01
Right, ok.
@krasserm And in the case for write availability within a physical location, I could have multiple local logs collaborating via replicated logs. Thinking of the use case of deploying on a more volatile environment like kubernetes, and not wanting to treat any JVM with more preference than another, which means dependencies on elected masters may not work too well for write availability.
Martin Krasser
@krasserm
Mar 08 2017 13:07

And in the case for write availability within a physical location, I could have multiple local logs collaborating via replicated logs.

Yes, that's possible

Josh Reese
@joshlreese
Mar 08 2017 13:32
@krasserm Great, seems like I understand where compromises can be made. I'm probably going to work toward sharding for minimizing write availability impact on node failure instead of requiring a ton of replication, but it's good to know the option is technically feasible.
Thanks for the chat!
Martin Krasser
@krasserm
Mar 08 2017 13:33
You're welcome, glad I could help!