Financial Transaction
write heavySummary
ACID-critical financial operations including ledger entries, account balance updates, and settlement. Every write must be durable, ordered, and exactly-once. Read operations for balance checks must be strongly consistent: replica reads are not acceptable for any operation that precedes a debit.
Example Systems
- ·Core banking ledger
- ·Payment processing (ACH, wire)
- ·Brokerage order book
- ·Crypto exchange settlement
- ·Insurance claims processor
Characteristics
Capacity
Access Patterns
Recommended Patterns
Patterns to Avoid
Basis
Financial system requirements are codified in PCI-DSS, SOX, and extensive industry literature on ACID compliance
Related Architecture Knowledge
Outbound: this entity affects
Financial transaction workloads benefit from the inbox pattern to ensure exactly-once payment processing even when the message broker delivers events more than once.
Full relationship →Financial transaction workloads benefit from event sourcing because the event log provides an immutable audit trail, enables temporal queries (balance at any past date), and makes the derivation of current state fully traceable: meeting regulatory requirements that state-mutation databases cannot satisfy.
Tradeoffs
- ·Event log growth is unbounded for long-lived accounts: snapshot and archival strategy required
- ·Query complexity increases: current balance requires snapshot + replay, not a single SELECT
- ·Schema versioning adds upcast complexity as event types evolve over years
Financial transaction workloads are vulnerable to deadlocks when concurrent transactions acquire locks on the same account or balance rows in different orders.
Full relationship →Financial transaction workloads are vulnerable to event ordering violations where applying a balance credit before a balance debit produces an incorrect intermediate state.
Full relationship →Used In Architecture Scenarios
Marketplace Platform
An e-commerce order lifecycle platform handling cart, checkout, payment, fulfillment, and returns across a mixed read/write workload where product discovery is read-heavy, checkout is write-transactional, and fulfillment is event-driven. The saga pattern orchestrates multi-step checkout: reserve inventory → charge payment → confirm order → notify fulfillment. PostgreSQL owns order records and inventory with row-level locking; Redis holds session state and cart contents with sub-millisecond access; RabbitMQ delivers fulfillment notifications with dead-letter handling; Elasticsearch serves product search and order history with faceted navigation. CQRS separates the write command path from the read model: the order read model is denormalized for fast order history queries without joining across domain tables.
Financial Ledger
A strict consistency financial architecture for double-entry accounting, payment processing, and audit trail management where every debit must have a corresponding credit, every state transition must be ordered and durable, and the complete history must be reconstructable without gaps. Event sourcing provides an append-only audit log; the outbox pattern guarantees at-least-once downstream event delivery without distributed two-phase commit (idempotent consumers deduplicate on event ID for effectively-once processing); PostgreSQL provides ACID guarantees for ledger entry atomicity.
Marketplace Platform
A two-sided marketplace architecture serving buyers, sellers, listings, transactions, search, and notifications from a shared infrastructure, where multiple independent domains must coordinate without tight coupling. Event sourcing captures every state transition; the saga pattern orchestrates multi-step transactions (create order, reserve inventory, charge payment, notify seller) with compensating transactions for partial failures. Kafka decouples domain event publication from consumption; RabbitMQ handles notification fanout; Elasticsearch serves listing search; Redis caches listing display and session state.