8
Architecture
Event sourcing vs CRUD for a banking ledger
Auditability ↔ Simplicity
Context
A ledger is append-only by nature, which makes event sourcing feel natural. But I've seen ES projects collapse under projection rebuilds, event versioning and team confusion.
Is an immutable double-entry journal_entries table (insert-only, enforced by permissions) "event sourcing enough" for most fintechs?
Event sourcingvsCRUD + audit table
Community verdict
Event sourcing 57%CRUD + audit table 43%
7 engineers · 2 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Event sourcing
CRUD + audit table
Simplicity →
Trade-offs
Dimensions
Event sourcingCRUD + audit tableout of 5
- Auditability
- 5Event sourcing scores 5 of 53CRUD + audit table scores 3 of 5
- Simplicity
- 2Event sourcing scores 2 of 55CRUD + audit table scores 5 of 5
- Temporal queries
- 5Event sourcing scores 5 of 5
Community discussion
2 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentAn insert-only double-entry table is the event log for money. Balances are projections you can rebuild with one SQL query. You don't need an ES framework to get the benefits.
Full ES pays off when the domain has rich state transitions (loan lifecycles, disputes), not just balances. Use it there and keep CRUD elsewhere.