javacassandracassandra-3.0lagom

Manipulate data from the database on multiple instances of the same service


I'm new to lagom and I'm asking about How can I manipulate data from the database on multiple instances of the same service?

Did read-side support that?

EDIT 1: I'm working on User management module.

I've put in place a ReadSide that listens to the User related events and updates the data in its database and I'm using the ReadSide to get the list of all the users.

I'm currently in Dev so I have a 1 cluster node that runs 1 instance of my user service and another 1 cluster node that runs Cassandra DB.

When deploying (to production) the user service and Cassandra to a multi-node cluster, I need to configure/create multiple (3 for the moment) instances of the user service.

Let's assume that the deployment will be as follows:

A user 'SMITH' calls a signup Webservice and instance 1 handles the request.

Later for some reason (i.g. maintenance, failure ) instance 1 is no longer available.

Will instance 2 or 3 recover from this unexpected "situation"? Can either of them handle ReadSide operations related to user 'SMITH'?


Solution

  • The three nodes will form an akka cluster and when one of the nodes get removed, the entities that were living there are moved to one of the other nodes.

    Detailed information about how that works can be founded here: https://doc.akka.io/docs/akka/current/cluster-sharding.html and https://doc.akka.io/docs/akka/current/cluster-sharding.html#how-it-works

    The same will happen with any read-side processors. I'm assuming here that you are using sharded tags. https://www.lagomframework.com/documentation/current/scala/ReadSide.html#Event-tags

    If don't use sharded tags, you will have only one read-side processor running. In one of the nodes.

    ps: For the record, because it was not clear from your last edit, there should be no dedicated Cassandra DB per node. All nodes should connect to the same Cassandra cluster. You should have different Cassandra nodes forming a cluster (not necessarily 3).