If Event sourcing is new to you, then before further reading, I recommend that you study at least some of the videos from the list below:

Short description

Event sourcing is an architectural principle. It differs slightly in different interpretations. Let’s introduce definitions to speak the same language:

  • Commands are accepted to change the data. For example, registerUser. The command may respond with an error if it considers that it is impossible to execute. The command generates 1+ `events'.
  • Events are a fait accompli. They are stored separately, for example, in some kind of table in the database. Or in Kafka. For example, UserRegistered. Let’s call the storage the `event store'.
  • Aggregate is the central term of transactionality. Each event is linked to it. For example, User(GUID="...."). It can be seen that the aggregate usually has a type (user) and an id (guid).
  • When reading data, sometimes an aggregate is created in memory, events are scrolled in it - thus getting the current state of the aggregate - and giving it in the desired form. This is called a `live projection’. It sounds strange at first glance, but with an aggregate size of up to 20 events, it works almost instantly.
  • And sometimes a regular database optimized for reading is used. It is called a projection'. Potentially, there may be several such databases (for example, Elasticsearch for full-text search and Postgres for regular queries). Usually one of them is called the main projection'.
  • To make projections, there are handlers that listen for the appearance of new events. They are called `projectors'.
  • If the projectors work synchronously with the addition of new events, then these are inline projectors'. Otherwise, they are asynchronous projectors'.
  • For side effects (communication with external systems, creation of secondary events) there is a separate type of handlers - `reactors'.

Projections can be divided into 3 types:

  • inline projections - runs as part of the command receiving mechanism
  • asynchronous (async) projections - work as a background process (and therefore with delays)
  • live projections - no additional storage is used, they are calculated dynamically from events

Event sourcing goes well with “CQRS”. In fact, event sourcing is a continuation of CQRS inside the backend of the application, including the database. Therefore, sometimes they are not distinguished, but they are different things.

Someone implements event sourcing in part of the application, someone completely.

I note that there are many variations to the scheme above, because this is a principle, and not even a specific architecture.

Examples of implementations

Commercial engines:

Open source engines:

Open source application templates:


It is not immediately obvious that 1C is the most popular event sourcing solution. It’s no wonder - there is intensive work with people and money, which means that a story is needed.

Document log – event store. Registers are projections. Etc .