Instead of keeping simply the present state of the data in a domain, employ an append-only store to record the whole history of actions made on that data. The store operates as the system of record and may be utilized to materialize the domain objects. This may ease activities in complicated domains, by removing the requirement to synchronize the data model and the business domain, while boosting speed, scalability, and responsiveness. It may also guarantee consistency for transactional data, and retain comprehensive audit trails and history that can allow compensatory actions. Most applications work with data, and the normal method is for the program to retain the current state of the data by updating it as users engage with it. For example, in the conventional create, read, update, and delete (CRUD) architecture a typical data operation is to take data from the store, make some adjustments to it, and update the current state of the data with the new values—often by utilizing transactions that lock the data.

The CRUD technique has significant limitations:
CRUD systems conduct update operations directly against a data store, which may slow down speed and responsiveness, and restrict scalability, owing to the processing overhead it demands.

In a collaborative domain with multiple concurrent users, data update conflicts are more frequent since the update operations take place on a single piece of data.

Unless there's an extra auditing system that captures the specifics of each operation in a separate log, history is lost.

The Event Sourcing pattern specifies a technique to handle activities on data that's driven by a succession of events, each of which is stored in an append-only database. Application code delivers a sequence of events that imperatively explain each action that has happened on the data to the event store, where they're saved. Each event describes a collection of changes to the data (such as AddedItemToOrder) (such as AddedItemToOrder).

The events are stored in an event store that operates as the system of record (the authoritative data source) regarding the present status of the data. The event store often broadcasts these events so that customers may be alerted and can manage them if required. Consumers might, for example, launch tasks that apply the operations in the events to other systems, or conduct any other connected activity that's necessary to accomplish the operation. Notice that the application code that creates the events is isolated from the systems that listen to the events.

Typical applications of the events broadcast by the event store are to preserve materialized representations of entities when activities in the application modify them, and for connection with other systems. For example, a system may keep a materialized view of all client orders that's utilized to fill elements of the UI. As the application adds new orders, adds or removes items on the order, and updates shipping information, the events that describe these changes may be handled and utilized to update the materialized view.

In addition, at any moment it's feasible for applications to read the history of events, and use it to materialize the present state of an object by playing back and consuming all the events linked to that entity. This may occur on demand to materialize a domain object while processing a request, or via a scheduled operation so that the state of the entity can be saved as a materialized view to assist the presentation layer.

The image presents an overview of the pattern, including some of the choices for utilizing the event stream such as constructing a materialized view, integrating events with other applications and systems, and replaying events to generate projections of the current state of certain entities.

The event store is the permanent source of information, and hence the event data should never be modified. The only method to update an entity to reverse a change is to add a compensatory event to the event storage. If the format (rather than the contents) of the persistent events has to change, maybe during a migration, it might be difficult to merge previous events in the store with the new version. It could be essential to cycle through all the events making adjustments so they're compatible with the new format, or create new events that utilize the new format. Consider placing a version stamp on each version of the event schema to keep both the old and the new event forms.

Multi-threaded apps and several instances of applications can be saving events in the event store. The consistency of events in the event store is crucial, as is the sequence of events that influence a single entity (the order that changes occur to an object affects its present state) (the order that changes occur to an entity affects its current state). Adding a timestamp to every event may assist to prevent difficulties. Another typical technique is to mark each event originating from a request with an incremental identifier. If two actions try to add events for the same entity at the same time, the event store might reject an event that matches an existing entity identification and event identifier.

There's no standard technique, or existing tools such as SQL queries, for reading the events to extract information. The only data that can be retrieved is a stream of events using an event identifier as the criterion. The event ID often corresponds to specific entities. The present state of an entity can be established solely by replaying all of the events that pertain to it against the initial state of that entity.