CODEWITHSUNDEEP
microservicesdomain-driven-designcqrseventual-consistency
Aleksander Chelpski
Aleksander Chelpski

Reputation: 771

Is a problem called eventual consistency If there is delay in processing command but I have only one database?

I know that a problem called eventual consistency dealing with two databases (a read database and write database).

But what if we have one database and use a message broker. If there is sometimes delay in processing a command and save results in a database, is this also a problem called eventual consistency or it isn't completely related to eventual consistency?

Upvotes: -1

Views: 77

Answers (1)

Levi Ramsey
Levi Ramsey

Reputation: 20541

At a high-level, what eventual consistency means (in a CQRS context) is "there can be an observable period of time from when a command is known to have succeeded and when the changes in state resulting from that command are visible (to queries)".

Accordingly, if you have a design where you receive a command (say over HTTP), process it, and publish a message to a broker to update a read-model (even in the same DB) and respond with a success, there is eventual consistency (it's possible for an immediate query of the read-model after getting the success response to query the read-model before the process consuming messages from the broker has updated the read-model).

If there's some other design where (for instance) you don't reveal whether a command actually resulted in a state change (e.g. you only acknowledge that the command was published to a broker), then that sidesteps this definition of eventual consistency (though as far as a user is concerned, this isn't that distinguishable from eventual consistency; to the extent that users/devices/etc. have their own view of how they've interacted with your application, there's arguably an inescapable level of eventual consistency).

Upvotes: 0

Related Questions