CODEWITHSUNDEEP
.netasp.net-coredesign-patternscqrs
Rajaram Shelar
Rajaram Shelar

Reputation: 7897

CQRS with event driven architecture but without event sourcing

Before posting this, I referred many sites and learning platforms but saw similar pattern of developing CQRS with event sourcing. Again to have proper events you need to follow DDD pattern. I have below questions.

  1. Can we keep read and write DB in sync just by publishing event from write model and consume it at read model using event handler and updating read database
  2. Why Event-Sourcing and replay of events needed if my requirement is to only see latest data
  3. I can manage audit of data as and when events reaches at event handler
  4. I can version messages based on timestamp in case if race condition.
  5. Please explain by doing steps 1,3 and 4, am I still following CQRS pattern?

FYI, I am using .NetCore 3.1, AWS Lambda services, MassTransit as a MessageBus and SQS as a transport.

Thanks in advance.

Upvotes: 1

Views: 1872

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57367

Can we keep read and write DB in sync just by publishing event from write model and consume it at read model using event handler and updating read database

Sort of; there are some trade offs. On the "happy path", it just takes a bit longer, because you have to wait for both writes to finish. When something goes wrong writing to the second database, it gets messy, because your two databases are no longer synchronized and you have to decide what, if anything you are going to do to recover.

If your reads and writes are to the same database, then that second problem goes away if you update them in the same transaction.

Why Event-Sourcing and replay of events needed if my requirement is to only see latest data

You don't. If you don't need the ability to reconstruct what your information looked like in the past, then you don't need event sourcing.

(You might think of it like source code - if you only ever need the latest version of your sources, then that simplifies the requirements for your "source control system".)

Please explain by doing steps 1,3 and 4, am I still following CQRS pattern?

Sure. "CQRS is simply the creation of two objects where there was previously only one." -- Greg Young, 2010. You may not be enjoying "all" of the advantages of CQRS (because you've made different trade offs).

The important thing is to be aware that you are making tradeoffs, and what the implications are.

Upvotes: 2

Levi Ramsey
Levi Ramsey

Reputation: 20591

As soon as you have separate data models for reading and writing, you're following CQRS. Event sourcing is not strictly required.

Note that accomplishing 1 in an application in a way which preserves the expected eventual consistency of the read side with the write side is rather difficult. You'll need to ensure that you publish the event if and only if the update of the write DB succeeded (i.e. there's never a case where you publish and don't update nor is there ever a case where you update but don't publish: if either of those could happen, you cannot guarantee eventual consistency). For instance, if your application does the update and if that succeeds, publishes the event, what happens if the process crashes (or you get network partitioned from the DB, or your lambda exceeds its time limit...) between the update and publishing?

The 2 best ways to ensure eventual consistency are to

  • update the write side DB by subscribing to the published event stream
  • use change data capture on the write side DB to generate events to publish

The first is at least very close to event sourcing (one could argue either way: I'd say that it depends on the extent to which your design considers the published event stream the source of truth). In the second, remember that you've basically lost all the contextual domain knowledge around the what's happened around that event: you're only seeing what changed in the DB's representation of the model.

Event sourcing and CQRS mutually improve each other (you can event source without doing CQRS, too, though it's only in certain applications that ES without CQRS is practical); event sourcing tends to let you keep the domain front-and-center and since it's append-only, it's the most optimized write model you can have.

Upvotes: 3

Related Questions