Event Sourcing over CRUD for Financial Audit Trails

Decided to implement Event Sourcing instead of standard CRUD in PostgreSQL for financial transaction audit trails.

PROBLEM: Standard CRUD overwrites previous states on UPDATE. When compliance requested history for transaction #8821, the team could not provide who changed the status from pending to approved.

ALTERNATIVES CONSIDERED:
- Database triggers to write to a history_logs table on every UPDATE: Rejected because business context is lost — triggers see only row changes (e.g., status 1 to 2) and cannot capture why the change happened or the user intent behind it.

DECISION: Move to Event Sourcing. Store a sequence of immutable domain events (e.g., TransactionCreated, TransactionApproved, StatusUpdated) instead of mutable current-state tables.

ARCHITECTURE:
- Kafka stores the immutable event log
- Materialized views in PostgreSQL provide fast reads for the frontend
- Event producers implemented in src/services/transactionService.ts
- Consumer/store logic in src/events/eventStore.ts

REFERENCE: Martin Fowler's 'Event Sourcing Pattern' article, which is the industry standard and handles the audit requirement perfectly.