Event Sourcing over CRUD for Audit Trails

The team decided to replace standard CRUD in PostgreSQL with Event Sourcing for financial transaction audit trails.

**What was decided and why:**
Instead of storing current state in a mutable table (CRUD), the team will store a sequence of immutable domain events (e.g., TransactionCreated, TransactionApproved, StatusUpdated) in Kafka. This ensures full audit compliance — every state change is preserved with its business context, not just the before/after row values.

**Alternatives considered and why rejected:**
1. Database triggers with a history_logs table (Charlie's suggestion): Rejected because triggers only capture row-level changes (e.g., status changed from 1 to 2) without business context — they don't record why the change happened or user intent. Alice explicitly noted this limitation.
2. Standard CRUD in PostgreSQL (current approach): Rejected because updates overwrite previous states, making it impossible to answer compliance questions like who changed transaction #8821's status from pending to approved.

**Implementation plan:**
- Event producers in src/services/transactionService.ts
- Consumer/store logic in src/events/eventStore.ts
- Materialized view in Postgres built from the Kafka event log for fast frontend reads

**Reference architecture:**
Martin Fowler's 'Event Sourcing Pattern' article — cited as the industry standard reference that handles the audit requirement perfectly.

**Files/code involved:**
- src/services/transactionService.ts (event producers)
- src/events/eventStore.ts (consumer/store logic)
- PostgreSQL (materialized view for reads)
- Apache Kafka (immutable event log)