Comment by ZHE ZHANG on "The Tri-Z Architecture: a Pattern for Layering ZIO Applications in Scala"

Hello, I saw in your "Beautiful Domain Logic" slide that you discussed Event Sourcing, and it seems like events are written to both a database and a message queue like Kafka. My questions are: Is Event Sourcing actually used in games? Does the database encounter performance issues due to the large number of event records? How is Event Sourcing integrated with sharding (like Shardcake)?

We do use event sourcing and events are written to DB only (we use Kafka to trigger some workflows but with different events and much smaller scale). So our DB usage is very write-heavy indeed. We use CockroachDB which makes it quite easily to scale. Event sourcing is independent from Shardcake: Shardcake provides us actors/entities that are distributed over our servers and addressable by ID, then in each entity we use event sourcing to manage the entity state (via snapshots/journals). So we use both but they are not directly connected.

I did see akka-persistent-cockroachdb in devsister's GitHub repository, but I assume this was used before migrating away from Akka, correct? Is the actual event sourcing interaction still using Akka / Pekko, or is it implemented separately? Also, are there any recommended ZIO libraries for interacting with CockroachDB?

Regarding state reads, I imagine they happen in shardcake's behavior. Then, the ZPure DSL is run, generating events. These events are sent to the DB. After successful DB operations, the in-memory state is updated using the same event handler lifted via lift. Is my description accurate? If STM is involved, it might be harder to conceptualize, as those cross-module events would also need to be atomically committed to the DB. Could you please advise if there are any good libraries for CockroachDB? Pierre Ricadat

Right, we are not using Akka persistence and instead use our own code. We're just using github.com/typelevel/doobie to communicate with the database.

We don't use STM in this part of the code actually, it's all one big state object in memory. When we load an actor, we load the latest snapshot and journals, replay those to have the latest state in memory. Then we serve reads and writes from that.

When we need a "fast access" to some data without loading the actor, we have some view tables in the database that are updated via Kafka: after the state is updated and saved in DB we publish some Kafka messages and a separate component reads those and update the views.

I'm also curious, if we use Kubernetes rolling updates, will the database read pressure be very high when the in-memory actor state is rebuilt? Pierre Ricadat

In our case it has never been a problem (since rolling updates start pods sequentially the pressure is not that high).

Search Hashnode