every entry, twice.
A software architect writing about the systems that move money.
I build and think about payments, ledgers, and real-time rails — and the correctness and trade-offs behind them. This is where I write it down.
Dropping the excess request isn't an option for a payment instruction. What's left is deferral — which turns a throughput problem into a prioritization problem with a deadline attached.
keep reading →The dual write can't be removed, only relocated. One payment capture — real schema, real transaction, real relay query, real consumer — killed at six points, with the state and the self-heal at each.
You can't get ordered delivery over a webhook channel, so stop asking for it. Three well-understood defenses — version numbers, refetch, and a state machine — and which one to reach for first.
0.1 + 0.2 isn't 0.3, and that's reason enough to store money as integer minor units, not floating-point.
Nobody demos reconciliation. But it's the process that decides whether your books are fiction or fact — the daily check that your ledger and the outside world still agree.
A June 2026 joint rulemaking would make US stablecoin issuers do customer identification like a bank. The interesting part isn't the KYC — it's where the rule draws the line between primary and secondary markets.
Most software can afford to lose a request. Money can't. That single constraint is why these systems are worth writing about.
The obvious way to store balances — a column you update — is the one that will eventually betray you. Here's why the accountants had it right.
An idempotency key turns a terrifying question — did that charge go through? — into a safe retry.
You can't deliver a message exactly once across a network. What you can do is process at-least-once and make duplicates harmless — which is the real job.
The big payments-messaging migration is mostly done. The format change was the easy part; what banks do with the richer data is the real story.