ADR-001: Event Sourcing & Transactional Outbox vs CRUD Persistence

# Architecture Decision Record: ADR-001

## Title: Event Sourcing & Transactional Outbox vs CRUD Persistence for Core Financial Ledger
- **Status:** Approved
- **Date:** 2025-08-15
- **Deciders:** Principal Systems Architect, Engineering Pod Lead, Lead Database Architect
- **Context:** Core Transaction Ledger Engine

---

## 1. Context and Problem Statement
Our core transactional platform requires processing high-frequency ledger balance mutations across multi-region nodes. Mutating database state via standard SQL `UPDATE` commands introduces concurrency locking contention, eliminates historical state auditability, and risks distributed race conditions during network partitions.

We must decide on a persistence paradigm that provides mathematically verifiable audit trails, sub-15ms P99 latency, and decoupled asynchronous projection streaming.

---

## 2. Considered Options
1. **Option A: Traditional CRUD with Row-Level Locking (PostgreSQL `SELECT ... FOR UPDATE`)**
2. **Option B: Distributed Event Sourcing with Transactional Outbox Pattern**
3. **Option C: External Managed Distributed Ledger SaaS**

---

## 3. Decision Outcome
**Chosen Option: Option B — Distributed Event Sourcing with Transactional Outbox Pattern.**

### Positive Consequences
- **Complete Audit Provenance:** The system state is a pure projection of immutable domain events; historical state can be replayed to any point in time.
- **Zero Lock Contention:** Writes are append-only inserts into the `events` table, avoiding row-level locks on balance records.
- **Atomic Asynchronous Dispatch:** Events and Outbox records commit in the same local database transaction, guaranteeing at-least-once delivery to Apache Kafka via Debezium CDC.

### Negative Consequences / Trade-offs
- Increased complexity in domain projection management and CQRS read-model rebuilding.
- Requires strict event schema versioning protocols using Protocol Buffers and Schema Registry.

---

## 4. Verification & Validation Rules
- All event payloads must be validated against compiled Protobuf schemas prior to persistence.
- Snapshots are generated every 1,000 events to bound read-model replay times under 250ms.