Assuming I have n instances of my query host, I will have n instances of the denormalizers listening to EventStore. If the aggregate on the command side is accumulating changes before saving/publishing then when the publish is finally made, then a stream of events will go out to the feed.
For example, let’s say the following 3 events were published when the Account aggregate is saved:
If there are 2 (or more) instances of the Query host all listening to the same Account stream, it stands to say that the one that picks up second could potentially process faster than the one that picks up first. That could mean that event 2 and 3 get processed in reverse order, leaving the denormalized view of the account in the wrong state, active instead of inactive.
Is there a practice to solve this race condition?