# Overview Event sourcing is... #flashcard - A technique where changes in application state is transmitted and stored as events which occur in a sequence. These events can be replayed to reconstruct the application's state at any point in time, making it an effective strategy for systems that require a detailed audit trail or the ability to reverse of replay transactions. - From an application point of view it is more meaningful to record the user’s actions as immutable events, rather than recording the effect of those actions on a mutable database. Event sourcing makes it easier to evolve applications over time, helps with debugging by making it easier to understand after the fact why something happened, and guards against application bugs. ## Pros #flashcard - **Fault tolerance**: If a worker crashes, another picks up the event - **Scalability**: Add more workers to handle higher load - **Observability**: Complete audit trail of all events - **Flexibility**: Possible to add new steps or modify workflows # Key Considerations ## Commands vs. Events - **Commands** - When a request from a user first arrives, it is initially a command: at this point it may still fail, for example because some integrity condition is violated. The application must first validate that it can execute the command. - **Events** - If the validation is successful and the command is accepted, it becomes an event, which is durable and immutable. An event typically expresses the intent of a user action, not the mechanics of the state update that occurred as a result of the action. # Implementation Details # Useful Links # Related Topics - [[Chronicle Data Model]] - [[Command Query Responsibility Segregation (CQRS)]] ## Reference #### Working Notes #### Sources - [Key Technologies for System Design in a Hurry](https://www.hellointerview.com/learn/system-design/in-a-hurry/key-technologies#streams--event-sourcing)