How can i ensure the availability of the current data in read side data source?

Lagom Lagom Development Mode
1

I am seeing the read data source is taking time in getting the current state after updates (considering only one).So the scenario is how lagom handles the write and read simultaneously. If one is updating the data how the other must get the updated data.But as per me it is not happening .Can anyone help me and give a pseudo or snippet for it.

2

Hi there,

I am afraid that your question does not have an easy answer, other than “it depends”.

This is the expected behaviour of Event Sourcing. If you are not-that-familiar with the pattern, below you can find a few articles that cover it in great detail:

  1. Lagom’s Advantages of Event Source
  2. Martin Fowler’s introduction of Event Sourcing
  3. Microsoft’s description of the Event Sourcing pattern

Keep in mind that what you observe is a problem inherent to distributed systems. Even if you rely on CRUD, when your single DB setup has reached it’s limits and you are force to scale out you’ll have to deal with data inconsistencies. Such is the nature of network communication.

Anyway, regarding your problem - as you are not providing much context - I will have to respond with a rather generic answer.

In short, if your application does in fact mandate strong consistency you’ll have to use an alternative persistence model. With Event Sourcing your Write and Read Side will often use separate infrastructure (often enough, even different engines). Consequentially, there will always be some latency between the writes. But please, bear in mind my remarks about the inherent problems with distributed systems. Having said that, in my experience, requiring strong consistency is rarely the case, as we live in a rather eventually consistent world, but lets plough on without resorting to polemics.

If you application does not have such strong consistency requirements, there are various techniques at your disposal which can provide a stronger guarantee:

  1. In terms of Event Sourcing, when reading something that the user may have modified, retrieve that information from the Aggregate Root they’ve modified. For an example, if you have withdrawn money from a bank account, send a GetState message to that account directly, instead of querying the Read Side.
  2. Or - I honestly do not recommend this, even though I’ve seen it used with success - you can force your UI (ugh!) to wait a certain amount of time before it queries the “read” API.
  3. Worst of all, you can modify the persistence module to write to the 2 databases “simultaneously”. Just remember an atomic write is going to be anything but trivial.
  4. Alternatively, you may design your application in such a way that it embraces the eventual consistency - but as I alluded to above, this very much depends on your application’s requirements. A task that is not always straight-forward.

Hopefully my remarks will be useful to.

3

Thanks @chmodas for the response.What i understood you are referring mainly to eventual consistency.

4

Hey @rsamrat073,

Perhaps I misunderstood the problem you are experiencing; in which case, I do apologize.

My understanding of the situation is the following: when you update an entity, the data is written to the Write Side (e.g. the journal) and then you observe a certain delay when the data is written to the Read Side.

May I kindly ask if this is not what you mean with

to further clarify by providing an example of what you are trying to achieve.

5

when you update an entity, the data is written to the Write Side (e.g. the journal) and then you observe a certain delay when the data is written to the Read Side.

@chmodas Yes my read data source is taking time in getting the latest update.The whole POC is in my personal laptop. For the time being i am just using cassandra as write and read side data source.

6

Hey Samrat,

In that case, I believe it’s fair to say my initial response was spot on, though it seems I could clarify it a bit.

The data source is taking time because the Read Side processor has to poll the Write Side for changes; every 100ms by default, if memory serves me right. It does not matter what database engine you use to persist the data, you would observe exactly the same with any other engine. The reason for this lies with Lagom’s choice for managing data persistence.

The point being, this is what you get out-of-the-box with Lagom. If you require/prefer a more “traditional” CRUD approach, you might want to compare it with Play (which Lagom uses under the hood), and see if it fits your requirements and environment better.

In any case, I highly recommend the articles I referred to in my initial response, they throw a lot more light on why one might want to employ the Event Sourcing pattern.