What is Event Sourcing?

Event sourcing records how a piece of data reached its current state, not just what the latest state is. For an order, the system may store events such as “created”, “payment captured”, “address changed”, and “shipped” in an append-only log.

How Does It Work?

The application receives a command, checks business rules, and writes a new event if the command is valid. The event is not overwritten or deleted; it is appended to the event store. To show current state, the system replays the relevant events in order or reads from projections built from those events.

Large streams often use snapshots so the application does not replay thousands of events from the beginning. Event sourcing is commonly paired with CQRS, where write models and read models are separated. In event-driven architectures, stored events can also notify other services, while DDD teams usually name events in business language.

Business Use

Event sourcing is valuable in payments, accounting, inventory, booking, and financial transaction systems where audit history matters. The answer to “why is this balance here?” lives in the event history, not only in the final row.

The trade-off is operational complexity. Event schemas, versioning, rollback behavior, privacy requirements, and projection rebuilds need deliberate design. For simple CRUD screens, event sourcing is often heavier than the problem requires.