The following considerations should be taken into account while implementing this pattern:
- A common problem faced with this pattern is concurrency. If more than one event arrives concurrently and are processed by different event handlers, then optimistic locking should be used to ensure that the state is consistent. To implement optimistic locking, the following flow should be followed for handling a request. To understand the mechanism in detail let's consider a flight seat reservation scenario:
- The user interface raises a command to reserve two seats. A command handler handles the command raises the BookSeats event which gets loaded in the Event Queue and saved in Event Store.
- The seat availability aggregate is populated by either querying all events in the Event Store. This aggregate is given a version identifier say X.
- The aggregate performs its domain logic and raises the SeatsReserved event.
- Before saving the SeatsReserved event, the event store verifies the version of the aggregate that raised the event. In case of concurrency, the version of the aggregate in store would be higher than the version of current aggregate.
Thus, you can avoid double booking by checking for versions before committing changes.
- Events cannot be changed. To correct the state appropriate events must be raised that compensate for the change in state.
- Event Sourcing pattern is based on domain driven design principles and therefore should follow terminology of the Ubiquitous Language. The names of events should be sensible in business context.
- Since events are basically messages, you need to keep standard messaging issues in consideration:
- Duplicate Messages: Your command handlers should be idempotent to handle duplicate messages so that they don't affect the consistency of data.
- Out of Order Messages: Choose FIFO message stores such as Service Bus Queues or Service Fabric Reliable Queue Collection to store events if you require messages to get stored in sequence.
- Poison Messages: Messages that repeatedly cause failure should be marked as failed and sent to a dead-letter queue for further investigation.