Projections

Once events are published, other parts of the system can react to them. One common reaction is to build or update state that can be queried later. This process is called a projection.

A projection takes in one or more events and produces derived state – often in the form of a read model.

In Our Library

Let's say a BookBorrowed event is published.

A projection might:

• Add a new loan entry to the member's active loan list
• Update the number of available copies for the book
• Record the loan in the member's history

Each of these projections runs independently, listening to events and updating their own view of the world.

Many Events, Many Views

A single event can feed multiple projections. For example, BookReturned might update:

• The member's current loans
• The availability status of the book copy
• A daily statistics dashboard

Because projections are separated, you can design each one for a specific use case – with its own data shape, performance characteristics, and storage.

Projections Are Replaceable

Projections are derived from events. That means they are not the source of truth – they can be:

• Rebuilt from scratch
• Reset or corrected
• Extended with new information

This makes them ideal for read-optimized views – fast, denormalized, and tailored to the UI.

Next up: Read Models – see how projections become queryable application state.