Event-Driven Architecture at Scale: Lessons From a Real-Time Payments Core.

An event backbone is only as strong as its weakest replay. Teams adopt event-driven architecture for scalability, but the discipline that makes it work is about auditability and recovery, not throughput.

Exactly-Once Is a Contract, Not a Feature

Idempotent consumers, deterministic replay, and a single writer per aggregate are what deliver the guarantee. Kafka's transactional API gives you atomicity at the producer level; the consumer side must still be built idempotently.

Where CQRS Pays for Itself

Payments workloads have a brutal read/write asymmetry — millions of balance queries for every mutation. Splitting the write model from the read model lets each be scaled and schemed independently, and lets the read model lag behind the write model by design.

The Outbox Pattern Is Non-Negotiable

Atomicity between a database transaction and a published event is the hardest correctness problem in the stack. The transactional outbox solves it: write the event to the same transaction as the domain change, and let a relay publish it. It costs little and removes an entire class of silently-lost-events bugs.

The proof in production: a payments core handling 1.2M transactions per minute across three regions, with event replay used for settlement reconciliation.