1
votes

As to my understanding, in event sourcing, events are recorded. However that would also mean a state changed first happened and thereafter we record the event. For example, assuming:

  1. A Client sends a command to a server to "Create user".
  2. The server validates the command and creates user i.e. stores new user in a database.
  3. The server then logs/stores a Created User event. i.e event sourcing.
  4. Created User event is propagated to subscribers

In the scenario above, how do we handle scenarios where step (2) succeeded but step (3) failed due to say network failures, database offline etc? The whole system would be in an indeterminate state now that there was a new user created but the event was never logged. How do we mitigate these types of failures? Or are the steps that I've listed above not the way to do event sourcing?

Thanks!

1

1 Answers

4
votes

This is not what happens exactly in Event sourcing, not even in plain CQRS.

In Event sourcing, after the command is validated, the domain events are generated by the source (the Aggregate in DDD) and then they are appended to the Event store in the first step. After that the subscribers (read models, projections, Sagas, external systems) receive and process the new domain events.

In CQRS, after the domain events are generated, they are applied to the Aggregate and then the Aggregate's state and the new events are persisted in the same local transaction, as the first step. Only after that the subscribers receive the events.

So you see? Your situation cannot happen: steps 2 and 3 are persisted atomically, they succeed or fail together.