Why I write about money movement

Most software can afford to lose a request. Money can't. That single constraint is why these systems are worth writing about.

I’ve spent most of my career on systems that move money, and I’ve decided to write about them in public. This is where that happens.

Here’s the thing that hooked me and never let go. Most software gets to be sloppy at the edges. A dropped analytics event, a page that loads twice, a cache that’s a little stale — annoying, rarely fatal. You retry, you move on. Money doesn’t grant you that.

A payment that executes twice isn’t a glitch, it’s someone’s rent charged twice. A balance that’s off by a cent isn’t rounding, it’s a ledger that no longer balances, and a ledger that doesn’t balance can’t be trusted for anything. “We lost a write” is a shrug in most systems and an incident report in this one.

That single constraint — you cannot lose or duplicate money, ever — ripples outward into everything. It’s why payments live and die on idempotency. It’s why the 500-year-old double-entry ledger is still the right data model. It’s why “exactly-once delivery” is a phrase I’ve learned to distrust. Layer on real-time deadlines (the customer is standing at the terminal) and regulation (an auditor will ask you to explain any number on any day), and you get some of the most demanding systems work there is. Correctness isn’t a feature you add. It’s the floor you build on.

So that’s the beat I’m covering here. Payments, ledgers, reconciliation, real-time rails, and the trade-offs underneath them. Not surface-level “fintech is eating the world” takes — the actual mechanics, and where they get hard.

One rule for myself: I’ll show the reasoning, not just the verdict. In this field the trade-off is the whole story. “Use an append-only ledger” is useless without the why, and the why is where the interesting decisions hide.

More soon.

Archie