0

I'm trying to understand the CQRS design. As far as I know now, every time a change to a model is saved, the (state) change is stored as a separate record. When reading a model, the model is constructed of the changes that are stored.

Like:

Model User
- username : "JohnDoe"
- email : "[email protected]"
- job : "Window cleaner"

Stored changes to User
CHANGE email TO "[email protected]"
CHANGE username TO "JohnDoe123"
CHANGE job TO "Pizza Delivery"
CHANGE username TO "JohnDoeFood"

When reading model, it will be:

Model User
- username : "JohnDoeFood"
- email : "[email protected]"
- job : "Pizza Delivery"

I wonder if I understand the concept correctly. I don't understand how this would work with models that could have thousands of changes or even more. I can't imagine every time the model is loaded the system looks up all changes and then constructs the model based on that whole bunch of changes.

Also, it lets me think a very little bit of a typical blockchain where, for example, a currency balance is determined/validated by evaluating all changes present in the chain.

3
  • 2
    Models are handled in CQRS the same way as they are in non-CQRS systems. The only difference between a CQRS and a non-CQRS system is that the CQRS system separates the Command responsibilities from the Query responsibilities. Compare the two illustrations shown here. Commented Nov 21, 2022 at 20:55
  • 2
    I can't imagine every time the model is loaded the system looks up all changes and then constructs the model based on that whole bunch of changes. -- Generally, it doesn't. It simply retrieves the record from the database, which is already the result of all of the changes made to it. There are systems that work the way you described, but that has nothing to do with CQRS. Commented Nov 21, 2022 at 21:01
  • Look up Event Sourcing. Regarding your specific question, you'd make "snapshot" of the aggregated events from time to time, and only reconstruct from that point on during retrieval - but still keep the ability to "roll" back the system to any previous state. Commented Nov 21, 2022 at 21:49

1 Answer 1

3

Your question is conflating several things.

  • CQRS does not factor into this. The question and answer would be exactly the same in a non-CQRS scenario.
  • Blockchain is a distributed ledger technology, which is orthogonal to the centralized event stream that event sourcing works with.

I can't imagine every time the model is loaded the system looks up all changes and then constructs the model based on that whole bunch of changes.

This is why usually the system stores snapshots. Snaphots essentially look like the kind of data you'd have in a non-event-sourced system; i.e. a straigh up table of current data.

However, importantly, snapshots are not considered as critical data. They can be safely deleted, and your system won't lose any data as everything is stored in the event stream.
Sure, it's going to take you some time and effort to regenerate your snapshots from your streams, but you didn't lose any data. Effectively, snapshots are just a form of cache which help you avoid constantly having to replay the event stream.

There are a few ways to do snapshots:

  • Always store the latest state, update the snapshot every time a new event is added
  • Make a snapshot every X events (e.g. 100), so you can start from a snapshot and only have to replay the latest events (never more than 99)
  • Make a snapshot at every set interval (e.g. every midnight), so you can start from a recent snapshot and only have to replay today's events)

Which approach makes sense for your scenario is highly contextual.

2
  • Out of curiosity. Are snapshots supposed to have historical? I mean, do you create new snapshots when following #2 and #3 or is there only one which gets updated all the time?
    – Laiv
    Commented Nov 22, 2022 at 10:19
  • 1
    @Laiv: It really depends on what you need. Generally, you only store "current" snapshots (or the best approximation of current, see bullet points in answer). That being said, I've also worked in projects where there was a lot of historical querying and we would keep some historical snapshots to speed up the process, but that's unrelated to getting the current state of the object, which is what snapshots mainly focus on.
    – Flater
    Commented Nov 24, 2022 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.