When is event sourcing worth its complexity?

With event sourcing, you do not store the current state. You store an append-only sequence of events, such as OrderPlaced and ItemAdded, and derive the state by replaying them. Read models are usually built separately, often with CQRS.

It pays off when:

• you need a full, trustworthy audit trail, as in finance or compliance,
• the history itself is valuable: temporal queries, "what did this look like last month", or debugging by replay,
• you need to build new read models or projections from past data,
• the domain is naturally event-driven and complex.

The costs are real: a different way of thinking, event schema versioning, eventually consistent read models, snapshots for long streams, harder ad-hoc querying, and the difficulty of deleting data for privacy rules, which needs techniques such as crypto-shredding.

For ordinary CRUD, a normal database with an audit table is simpler. I would apply event sourcing only to the parts of the system that benefit, not everywhere.