CQRS-Read and Write Consistency

[Prakhyat Mallikarjun]

Team,

We are taking CQRS/DDD/Event sourcing approach to build our app.

Write side makes use of PersistentView to push events from write side to STATE at read side.

But this happens asynchronously as PersistentView pulls events from its PersistentActor at configured interval. The PersistentView  is the hard link between read and write side. If anything happens to this link, the read and write will be out of sync.

If PersistentView fails or is down, the events will be keep on piling up at write side and query side will be in out of sycn with write side.

How to make sure the link is durable? The read and write side are always kept in sync and consistent. 

-Prakhyat M M

[Greg Young]

By definition in what you said they are not consistent they are just close when link is up they may be 150ms off

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Prakhyat Mallikarjun]

Hi Greg,

Thanks. I got your point and understand.

But what would be the response to the client? as write side has saved event but same is not reproduced at read side.

How to handle client interaction in CQRS environment? Do you expect request and response should be asynchronous(i.e.websockets)? 

-Prakhyat M M

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael L Perry]

That's the beauty of CQRS. You get to define "eventual" in eventual consistency. How important is it to have the read and write side in sync? Based on the answer to that question, add redundant persistent views. You want more consistency, you pay for it.

[Sebastian Good]

Dealing with eventual consistency in your user interface can be tackled in a number of ways -- the most elegant involve essentially subscribing to events which notify you when read models have changed. It takes a change in approach, but pays off with the ability to easily add multiple asynchronous data sources to your program.

If you don't have multiple asynchronous services, or if you don't need specialized write models for performance, or you don't need to "scale", then consider keeping your read and write models in the same database and committing them with the same transaction. Event sourcing and reactive programming are deeply empowering, but they also require you to think differently.

For instance, you must accept that typical MVC code like "commit edit to ID(5), redirect to view ID(5)" will quite often fail to show latest updates. Instead, you will need to "bind this UI to ID(5) as it updates, send update to ID(5)".

Sebastian Good

On Wed, Sep 24, 2014 at 9:37 AM, Michael L Perry <mpe...@mallardsoft.com> wrote:

That's the beauty of CQRS. You get to define "eventual" in eventual consistency. How important is it to have the read and write side in sync? Based on the answer to that question, add redundant persistent views. You want more consistency, you pay for it.

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

How does adding more redundant eventually consistent persistent views
make them consistent? It may make them more available or at a lower
SLA but consistency has a rather formalized definition which adding
view models will not help in any way to achieve

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Greg Young]

Asynchronous is one way of dealing with things. There are many others.

In your current system when I update some data and then read it do you
take a pessimistic lock on that data?

>>> email to dddcqrs+u...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Studying for the Turing test
>>

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+u...@googlegroups.com.

[Michael L Perry]

I was interpreting the question as that the persistent view update process being offline, thus making the read side out of date (inconsistent). But, yes, if the persistent view itself is offline, then the system is simply unavailable.

 

[Greg Young]

Look up the definition of consistency in database terminology. Even in
working modes the read model is "inconsistent" by the definition of
consistency (updating 100ms later does not make something consistent,
the read model would always be inconsistent).

[Michael L Perry]

Sure, but by that definition, "eventual consistency" is not "consistency". :)

[Greg Young]

"That's the beauty of CQRS. You get to define "eventual" in eventual
consistency. How important is it to have the read and write side in
sync? Based on the answer to that question, add redundant persistent
views. You want more consistency, you pay for it."

The is no "more or less consistency" there is consistency or not.

On Wed, Sep 24, 2014 at 3:44 PM, Michael L Perry <mpe...@mallardsoft.com> wrote:
> Sure, but by that definition, "eventual consistency" is not "consistency".
> :)
>

[Kijana Woodard]

Eventual consistency means "not consistent" with a promise that "the read model" will be consistent with "this write" at some point in the future. At that point in the future, the read is still "not consistent" with the write model.

Update speed is irrelevant. The big revelation for eventual consistency is the promise. Before, we thought that if the model was *ever* inconsistent, we were totally ruined. The promise to bring things in line eventually [backed by an SLA] gives us the ability to relax consistency for a given scenario.

"We are taking CQRS/DDD/Event sourcing approach to build our app."

Consider using what works for each case rather than trying to build the entire app the same way. As Sebastian mentioned, reading and writing from the same store gives you immediate consistency. You can still do CQRS because you can separate the models. The fact that there is one data store for both models is irrelevant. Generally, if you're doing POST/Redirect/GET, you're probably doing CRUD. 

If you feel there is value for ES in a certain case [quite reasonable feeling, btw], make sure the SLA for reads are explicit. Just as you can write to a single rdbms and do CQRS, the same is true for ES. There's nothing stopping you from loading up the Events from the event store to build your UI....as long as it meets your SLA. Make compensations for that [snapshots, etc].

[Kyle Cordes]

On Wednesday, September 24, 2014 at 10:41 AM, Kijana Woodard wrote:
> Update speed is irrelevant. The big revelation for eventual consistency is the promise. Before, we thought that if the model was *ever* inconsistent, we were totally ruined. The promise to bring things in line eventually [backed by an SLA] gives us the ability to relax consistency for a given scenario.

My revelation on this came while watching that enormous 6+ hour class video of Greg (I’m still not sure if that is supposed to be online or if it is some kind of bootleg). It is simply this. All systems are already only at best eventually consistent whether we like it or not. Data displayed on the screen, might not be the truth anymore. Information moves at a certain speed at best. Simultaneity is an illusion, not reality. I saw this expressed recently in a different talk as: start with the physics rather than computer science when thinking about this.


--
Kyle Cordes

http://kylecordes.com

[João Bragança]

http://en.wikipedia.org/wiki/Relativity_of_simultaneity

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/