Event-Driven Architecture When the Payload Is Money

Most writing about event-driven architecture optimises for throughput and decoupling. Both matter. Neither is the binding constraint when a duplicated message means a customer is paid twice.

At-least-once is the default, and it is a design input

Practical messaging systems deliver at least once. Exactly-once semantics, where offered, are usually exactly-once processing within a bounded scope — not a guarantee that spans your side effects.

So the question is not whether a message can arrive twice. It is what your handler does the second time. If that answer is not 'nothing', the design is not finished.

Auditability beats cleverness

In financial systems, being able to reconstruct what happened is worth more than shaving latency. Every state transition recorded, with the event that caused it, turns an incident investigation from archaeology into a query.

• Deterministic idempotency keys derived from the business event
• State transitions recorded, not inferred
• Dead-letter queues that a human actually reviews
• Reconciliation as a continuous process, not a month-end scramble

Ordering is usually a modelling problem

Teams reach for strict global ordering far more often than they need it. Most apparent ordering requirements dissolve once operations are made commutative or the state machine is made explicit about which transitions are legal from where.