Event sourcing and CQRS are powerful patterns with legitimate use cases and a reputation for over-application. The 2021 state of the patterns: clearer about where they fit and where they don't.
What event sourcing actually is
In event sourcing, the system's state is derived from an append-only log of events rather than stored directly. Instead of updating a row in a database, you append an event: 'OrderPlaced', 'PaymentReceived', 'OrderShipped'. The current state is computed by replaying events from the beginning (or from a snapshot). The event log is the source of truth.
The legitimate benefits
Event sourcing provides: a complete audit trail by default (every state change is an event with a timestamp and cause), the ability to replay events to rebuild read models or fix bugs in projections, temporal queries (what was the state at any past point), and natural integration with event-driven architectures. For financial systems, compliance-heavy domains, and collaborative editing, these benefits are genuine.
CQRS as the read model solution
Event sourcing produces an event log that is not directly queryable. CQRS (Command Query Responsibility Segregation) separates the write model (commands, events) from the read model (projections, views). Read models are built by subscribing to the event stream and maintaining denormalised, query-optimised views. Each query surface gets its own read model. The complexity cost is two code paths for every data access.
When not to use it
Event sourcing adds significant complexity: event schema versioning (how do you handle events from three years ago when the schema has changed?), snapshot strategies, read model rebuild times, and the cognitive overhead of thinking in events rather than state. For CRUD applications, reporting systems, or domains where temporal queries and audit trails are not primary requirements, event sourcing adds complexity without benefit. The pattern is often adopted for its intellectual appeal rather than its practical necessity.