Event Sourcing Trade-offs

Powerful, and expensive

Event sourcing adds real costs. Querying current state across many aggregates needs projections, since you cannot just SELECT from the event store. The learning curve is steep: aggregates, streams, versioning, eventual consistency. Schema evolution lasts forever, because history cannot be rewritten. Deleting personal data is tricky with immutable events; common approaches are keeping personal data out of events (store a reference), or crypto-shredding: encrypt each person's data with a per-person key and delete the key when erasure is required. Event sourcing earns its cost where the history itself is valuable: finance and ledgers, auditing and compliance, complex domains with temporal questions, and collaborative or conflict-heavy domains. It is rarely worth it for simple CRUD, and it is usually applied to selected bounded contexts, not to a whole company.

Where event sourcing fits

A rough guide for design reviews.

good fit                                   poor fit
-----------------------------------------  -----------------------------------------
ledgers, payments, wallets, trading        simple CRUD (profiles, settings, catalogues)
audit-heavy / regulated workflows          reporting-only data
"what did we know at time T?" questions    teams new to DDD and async systems
many read models from one history          data that must be truly deleted often
complex domain with rich business events   tight deadlines with no room for learning

Do not event-source by default

Choosing event sourcing for the whole system because one module needs an audit trail is a common and costly mistake. An append-only audit table or CDC may give you the history at a fraction of the effort.

Quick check: How can personal data be made unreadable in an immutable event store?

• Crypto-shredding: encrypt per person and delete that person's key
• Edit the old events
• Rename the stream
• Increase retention