Event Sourcing/CQRS doubts about aggregates, atomicity, concurrency and eventual consistency

Question

I'm studying event sourcing and command/query segregation and I have a few doubts that I hope someone with more experience will easily answer:

• A) should a command handler work with more than one aggregate? (a.k.a. should they coordinate things between several aggregates?)
• B) If my command handler generates more than one event to store, how do you guys push all those events atomically to the event store? (how can I garantee no other command handler will "interleave" events in between?)
• C) In many articles I read people suggest using optimistic locking to write the new events generated, but in my use case I will have around 100 requests / second. This makes me think that a lot of requests will just fail at huge rates (a lot of ConcurrencyExceptions), how you guys deal with this?
• D) How to deal with the fact that the command handler can crash after storing the events in the event store but before publishing them to the event bus? (how to eventually push those "confirmed" events back to the event bus?)
• E) How you guys deal with the eventual consistency in the projections? you just live with it? or in some cases people lock things there too? (waiting for an update for example)

I made a sequence diagram to better ilustrate all those questions

(and sorry for the bad english)

Answer 1

If my command handler generates more than one event to store, how do you guys push all those events atomically to the event store?

Most reasonable event store implementations will allow you to batch multiple events into the same transaction.

In many articles I read people suggest using optimistic locking to write the new events generated, but in my use case I will have around 100 requests / second.

If you have lots of parallel threads trying to maintain a complex invariant, something has gone badly wrong.

For "events" that aren't expected to establish or maintain any invariant, then you are just writing things to the end of a stream. In other words, you are probably not trying to write an event into a specific position in the stream. So you can probably use batching to reduce the number of conflicting writes, and a simple retry mechanism. In effect, you are using the same sort of "fan-in" patterns that appear when you have concurrent writers inserting into a queue.

For the cases where you are establishing/maintaining an invariant, you don't normally have many concurrent writers. Instead, specific writers have authority to write events (think "sharding"); the concurrency controls there are primarily to avoid making a mess in abnormal conditions.

How to deal with the fact that the command handler can crash after storing the events in the event store but before publishing them to the event bus?

Use pull, rather than push, as the primary subscription mechanism. Make sure that subscribers can handle duplicate messages safely (aka "idempotent"). Don't use a message subscription that can re-order events when you need events strictly ordered.

How you guys deal with the eventual consistency in the projections? you just live with it?

Pretty much. Views and reports have metadata information in them to let you know at what fixed point in "time" the report was accurate.

Unless you lock out all writers while a report is being consumed, there's a potential for any data being out of date, regardless of whether you are using events vs some other data model, regardless of whether you are using a single data model or several.

It's all part of the tradeoff; we accept that there will be a larger window between report time and current time in exchange for lower response latency, an "immutable" event history, etc.

---

should a command handler work with more than one aggregate?

Probably not - which isn't the same thing as always never.

Usual framing goes something like this: aggregate isn't a domain modeling pattern, like entity. It's a lifecycle pattern, used to make sure that all of the changes we make at one time are consistent.

In the case where you find that you want a command handler to modify multiple domain entities at the same time, and those entities belong to different aggregates, then have you really chosen the correct aggregate boundaries?

What you can do sometimes is have a single command handler that manages multiple transactions, updating a different aggregate in each. But it might be easier, in the long run, to have two different command handlers that each receive a copy of the command and decide what to do, independently.