# Event Sourcing Trade-offs — Event-Driven Architecture & CQRS

Source: https://www.skillbyai.com/en/event-driven-architecture/s-tradeoffs

> Decide when event sourcing is worth it and handle deletion and querying.

## 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.

```text
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.

**Quiz:** How can personal data be made unreadable in an immutable event store?

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

*Answer:* Crypto-shredding: encrypt per person and delete that person's key. Deleting the key makes the encrypted data unreadable without rewriting history.