Event Sourcing over CRUD for Financial Transaction Audit Trails

DECISION: Adopt Event Sourcing over standard PostgreSQL CRUD for the financial transaction audit trail to satisfy compliance audit requirements.

WHY: The current CRUD approach overwrites previous row states, making it impossible to retrieve historical changes. When compliance requested the history of transaction #8821, the team could not determine who changed the status from pending to approved.

ALTERNATIVES CONSIDERED AND REJECTED:
1. Database triggers + history_logs table: Rejected because triggers only see raw row changes (e.g., status changed from 1 to 2) and lose all business context — they cannot capture *why* a change happened or the user intent behind it.

APPROACH: Store a sequence of immutable domain events (e.g., TransactionCreated, TransactionApproved, StatusUpdated) as the source of truth, using Kafka for the immutable event log. A materialized view in PostgreSQL is then built for fast reads on the frontend.

FILES/ATTACHES:
- src/services/transactionService.ts — event producers
- src/events/eventStore.ts — consumer/store logic

REFERENCE: Martin Fowler's 'Event Sourcing Pattern' article — the architecture follows this reference exactly.

CONSENSUS: Led by Alice (Lead); Bob (Eng) will implement the event producers in transactionService.ts and the consumer/store in eventStore.ts; Charlie (Security) raised the reference-architecture question.