Move $1 from wallet A to wallet B. A million times a second.

That’s the whole problem, and it is the best-structured chapter in this series — because rather than presenting one architecture, it walks through four, each one solving what the previous one broke:

1. In-memory sharding — fast, and loses money when a node crashes
2. Distributed transactions — correct, and you can’t explain why a balance is what it is
3. Event sourcing — auditable, and too slow going over the network
4. Distributed event sourcing — fast, reliable, and shardable

Watching a design fail four times is more instructive than seeing the final answer, so that’s how this is written.

Here is the throughput requirement for a payment backend serving an Amazon-sized store:

1,000,000 transactions/day ÷ 100,000 seconds = 10 TPS

Ten transactions per second. Less than the hotel reservation system, which was already the smallest number in this series.

And payments are harder than either. Because the failure mode is not a slow page or a stale metric — it’s charging someone twice, or taking their money and not paying the seller. There is a real person, a real bank statement, and in many jurisdictions a regulator.