Lagom patterns without clustering

Lagom
1

My team has been using Lagom with the Persistent Entity, Read-Side Processor, and Event Sourcing patterns for nearly three years. One big change we made two years ago was to swap from Cassandra to Postgres for storage. We fully believe that Cassandra is the more-performant and applicable software for this infrastructure, but were willing to take performance and (maybe) cost hits in the move to postgres to save on the management cost of Cassandra as well as the consistency-guarantees when we make mistakes other software around Cassandra (like causing a split brain scenario).

While Cassandra had the highest complexity and management costs of our Lagom usage in the past, the Clustering, at least for the Persistent Entitites (not the Read Side processors) also is a pretty significant complexity, both in understanding how they system works, and dealing with degradation of instances. Again, we fully believe that Clustering is the most-performant solution given the other Lagom patterns, but might be interested is reducing the performance for a reduction in complexity and increase in costs. It would be a useful switch to have to take some performance hit in exchange for complexity, but then if we do need the performance, use the same underlying patterns Lagom provides but with clustering turned on.This pattern of course would cause consistency problems with Cassandra, but with postgres, the unique constraint on the persistent entity id and version would be the safety net.

Also two years ago, I investigated if there was any way to turn off clustering (and basically in-memory persistence so that we don’t have a consistency problem that arises without clustering) while maintaining the rest of the Lagom patterns. I recall finding that it would not only require hooks added to Lagom, but Akka-persistence and even possibly akka-persistence-jdbc.

I don’t have any artifact of that investigation handy. Has anyone tried doing this, or have any idea if it is more-possible now than it was two years ago?

2

I don’t think this sis entirely true. While the JDBC implementation includes mechanisms to prevent journal forking, any non-sharded usage of persistent entities (clustered or not) suffers a problem:

  • node A loads entity User-smith and hydrates it with journaled events
  • node B loads entity User-smith and hydrates it with journaled events
  • node A processes a command. produces events and mutates the User-smith state
  • node A is now out of date and won’t serve correct read-only data until the in-memory copy is passivated and a new instances re-hydrated.
    (I’m not talking about state-changing commands, but those could also present issues)

Lagom is highly dependant on running on an Akka cluster ATM.

Cheers,

3

Absolutely. To do this, I’d need persistent entities not to really persist in memory at all. Every call from an external user would need to hydrate the entity.

Ok, thank you for the response. Totally fair, and my idea is definitely against the intended architecture of Lagom.