Event sourcing for transaction platforms

Event sourcing is a pattern that gets oversold in general and undersold for the specific case of payment transaction platforms. The properties event sourcing gives — immutable historical record, replay for audit, event-driven downstream — happen to align with what a payment platform needs, if you accept some carve-outs.

Written February 2026 from platform architecture engagements.

Where it fits well

• Transaction lifecycle as events. AUTHORIZED, CAPTURED, REFUNDED, REVERSED, RECONCILED — the transaction is the event stream. This is the natural model.
• Regulatory audit. Replaying the event stream to show what happened during a specific window is exactly what auditors ask for.
• Multiple projections. The transaction store, the merchant view, the fraud analytics store — each is a projection off the same event stream, kept in sync by replay.

Where you carve out

• Query performance. Don't try to answer "how many transactions today" by replaying events. Have a projection.
• Reference data. Merchants, connectors, configuration — not event-sourced. Regular tables.
• PII. Cardholder data doesn't belong in an event stream that gets replayed. Store references; keep the sensitive data in a vault with its own access model.

The operational reality

Event sourcing pushes complexity from "keeping the database consistent" to "keeping projections in sync". The trade-off is usually worthwhile for a payment platform because the audit and reconciliation properties are worth the projection complexity.

The failure mode is not building projection catch-up as first-class ops work. Projections drift; catch-up is a routine operation; if you don't build the tooling, an outage becomes a manual recovery exercise. Build the tooling before you need it.