Decision guide
Event Sourcing vs CRUD + Audit Log vs CDC
How should you capture history and publish changes?
Side by side
| Criterion | CRUD + audit log | CDC (change data capture) | Event sourcing |
|---|---|---|---|
| Source of truth | Tables | Tables | Event log |
| Captures business intent | Partially (audit reason) | No (row diffs) | Yes |
| Rebuild state at any time | No | Limited (log retention) | Yes |
| New read models from history | No | From snapshot onward | Yes, full replay |
| Complexity | Low | Medium (infra) | High |
| Ad-hoc SQL queries | Easy | Easy | Via projections |
When to choose each
CRUD + audit log
Normal tables plus an append-only audit/history table.
Choose when
- Most business apps
- Compliance needs simple 'who changed what'
Avoid when
- Rebuilding state or new views from complete history
CDC (change data capture)
Stream row changes from the database log (Debezium).
Choose when
- Syncing search/caches/warehouses
- Publishing changes without touching app code
Avoid when
- Capturing business intent (rows ≠ events)
Event sourcing
Events are the source of truth; state is derived.
Choose when
- Complex domains with valuable history (ledgers, claims)
- Temporal queries and replays
Avoid when
- CRUD-heavy domains
- Teams new to the pattern under time pressure
Verdict
Start with CRUD + audit log; add CDC/outbox to integrate systems; reserve event sourcing for bounded contexts where history and intent are core business value.
Learn more
- Event Sourcing & CQRS
- Distributed Systems for Backend Engineers
- Databases & Transactions
- Messaging & Queues
- Track created/updated timestamps and users with JPA auditing (Spring Boot)
- Publish events reliably with the transactional outbox (Spring Boot)