How to manage read requests in an event sourced application

Great question Nick. The concept you are missing is 'Projections'. When an event is persisted you then broadcast the event. You projection code listens for specific events and then do things like update and create a 'read model'. The read model is a version of the end state (usually persisted but can be done in memory).

The nice thing is that you can highly optimise these read models for reading. Say goodbye to complicated and inefficient joins etc.

Becuase the read model is not the source of truth and it is designed specifically for reading, it is ok to have data duplication in it. Just make sure you manage it when appropriate events are received.

For more info check out these articles:

• Overview of a Typical CQRS and ES Application **
• How to Build a Master Details View when using CQRS and Event Sourcing
• Handling Concurrency Conflicts in a CQRS and Event Sourced system

Hope you find these useful.

** The diagram refers to denormalisation where it should be talking about projections.

You can query the event store. The actual method of querying is specific to every implementation but in general you can poll for events or subscribe and be notified when a new event is persisted.

The event store is just a persistence for the write side that guaranties a strong consistency for the write operations and an eventual consistency for the read operations. In order to "understand" something from the events you need to project those events to a read-model then query the read-model. For example you can have a read-model that contain the current balance for every account as a MongoDB collection.