0

I'm currently playing around with a CQRS implementation and I'm having some trouble understanding the following concept:

Event Bus for publishing update events (required): Whenever the write database is updated, a change notification is published as an event on the event bus. Interested parties can subscribe to the event bus to be notified when the database is updated. One such party is an event processor for the query database, which receives update events and processes them by updating the query database accordingly. In this way, every time the write database is updated, a corresponding update is made to the read database to keep it in sync. source

How does an event processor actually know how the database is going to be accessed by a read service?

Let's say I have a read service that accepts queries from the outside world. It retrieves data to satisfy this request from some kind of key-value database, reading specific keys according to some read-side data model / schema (could be protobuf, graphql, etc).

Does this schema need to be shared with the event processor in order for it to know which keys to write to? If so, doesn't this introduce tight coupling between the event processor and the read service? Among other problems, I will now need to worry about the order of deployment of these services, making sure that if I ever update the read model, the event processing service is deployed before the read service (or else the read service may read from keys which are never written to).

Am I fundamentally misunderstanding something about how this typically works?

user7467314
  • 141
  • Keep in mind that CQRS (with Event Sourcing in this case) isn't about decoupling, it's about guaranteed, reliable, asynchronous writes, with resilience against infrastructure failures. Typically this is associated with significant Increased complexity and costs in many areas, including within the codebase itself, the automated tests, CI and Deployment processes, release management and configuration management. These costs are just some of the typical trade-offs which feed into the cost of providing such guarantees. – Ben Cottrell Jun 15 '22 at 04:52
  • On a note about deployment, there are some strategies (e.g. Blue-Green environments) that you can use to mitigate disruption from deployment and minimise the need to care about deployment order. – Ben Cottrell Jun 15 '22 at 04:55
  • If your schema changes too much, you can start up a new read-side database by processing the same events from the beginning. – user253751 Jun 15 '22 at 13:10

0 Answers0