This query is performed. Which means: the query service received the request; it did not have it cached; requests from database; provides stored response to requester;
the command "set current address of business X" is performed. This updates the database.
This query is performed again. Which means: ???
There are a number of options for ???. Which depend heavily on the application requirements. Does the query service provide the stored response again? That would be inconsistent with the data in database but maybe fine for requirements. When is the stored value in the query service expired? After a certain amount of time? Never? When an event is received from the database?
I've found that when considering CQRS from the start the consistency requirements are easier to determine: There is no assumed consistency between query and command. Which then directs the design to have a nice separation of concerns while still ensuring the consistency requirements.
This is different from traditional non-CQRS designs: Those often assume a transaction encompassing both reads and write requests. Which ensures consistency but avoids having to consider what's actually required for the application... Until you're sitting there wondering why hundreds of rows are being locked to +1 a number XD
I think in this case you should give up on consistency for the sake of availability. Of course this does not work in every system, but maybe this system does not need to know the exact updated address of the user (it is not a service trying to send you a letter, it just want to see your general profile to sell you a car).
In those system, the cache data could be invalidated after que Command event was done.
But again, it all depends on what system are we working with
I have two separate implementations at the moment that fit both models. One is a postcode lookup service, so the address that is found absolutely needs to be returned without fail (highly available).
Another implementation has a dataset that is used in numerous different places, but can be up to 15-30 minutes old without causing any issues (eventual consistency, looser coupling).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
See also: jepsen.io/consistency/models/read-...
Imagine the following sequence of events:
there is a query "latest address of business X".
This query is performed. Which means: the query service received the request; it did not have it cached; requests from database; provides stored response to requester;
the command "set current address of business X" is performed. This updates the database.
This query is performed again. Which means: ???
There are a number of options for ???. Which depend heavily on the application requirements. Does the query service provide the stored response again? That would be inconsistent with the data in database but maybe fine for requirements. When is the stored value in the query service expired? After a certain amount of time? Never? When an event is received from the database?
I've found that when considering CQRS from the start the consistency requirements are easier to determine: There is no assumed consistency between query and command. Which then directs the design to have a nice separation of concerns while still ensuring the consistency requirements.
This is different from traditional non-CQRS designs: Those often assume a transaction encompassing both reads and write requests. Which ensures consistency but avoids having to consider what's actually required for the application... Until you're sitting there wondering why hundreds of rows are being locked to +1 a number XD
I think in this case you should give up on consistency for the sake of availability. Of course this does not work in every system, but maybe this system does not need to know the exact updated address of the user (it is not a service trying to send you a letter, it just want to see your general profile to sell you a car).
In those system, the cache data could be invalidated after que Command event was done.
But again, it all depends on what system are we working with
Yeah, that's a great point.
I have two separate implementations at the moment that fit both models. One is a postcode lookup service, so the address that is found absolutely needs to be returned without fail (highly available).
Another implementation has a dataset that is used in numerous different places, but can be up to 15-30 minutes old without causing any issues (eventual consistency, looser coupling).