corebank

No operation could be allowed to leave an account negative. Not “make it hard”: make it so that no code path is capable of it, including the one I write next month without remembering this rule.

An if balance < amount in the service layer, plus a balance column in Postgres. That is what almost everyone does, and it loses for a concrete reason: a check covers the routes that exist on the day it is written. The new route, the data-migration script, the internal adjustment endpoint — each is an opportunity to skip it. And the balance column introduces a second source of truth that can disagree with the history that supposedly explains it.

No application path can skip the check because there is no check to skip. The cost is real and it is two things: it forces an equity account as the counterparty — deposits debit world, withdrawals credit it — and it gives up querying balances with ad-hoc SQL, because the balance is not in Postgres. When I want a balance, I ask the ledger.

Amounts arrive as JSON, which does not distinguish an integer from a floating-point number. They had to be converted to the minor unit without losing a cent on the way.

float64(8.87) * 100 does not give 887. It gives 886, because 8.87 has no exact binary representation and the product lands just below. One cent per transaction, silently — and in a double-entry ledger a cent that does not reconcile is an entry that does not close.

Decoding into float64 and rounding at the end, which is the default path of any JSON library. And a third-party decimal type: it fixes the arithmetic but not the edge that matters, because the float was already lost in the decoder before the decimal exists.

There is a hand-written UnmarshalJSON that most people would consider unnecessary, and a test pinning the exact difference between 886 and 887 so nobody “simplifies” it later. The cost is that extra complexity at the edge of the system, concentrated in one file, in exchange for the rest of the code never having to think about it.

The ledger holds the movement of money; Postgres holds everything else — who the user is, what the account is called, what the movement’s description said. One operation writes to both, and no transaction spans them.

The classic problem: if the process dies between the two writes, what is left? A movement in the ledger with no row to explain it, or a row promising a movement that never happened.

A two-phase commit across the two engines, which requires both to support it and adds a coordinator that can also fall over. And an outbox with a worker, which is the right answer at scale but which I would expect to cost latency and one more moving part for a problem that a deterministic identifier solves here.

Retries are safe by construction: retrying means writing the same identifier, and the ledger rejects the duplicate. And a reconciliation sweeper walks the rows whose outcome was never recorded, reads the ledger, and makes the row agree. It never moves money — it only records what the ledger already did. The cost is that this process exists and has to be understood: a bug there can misreport a movement, but it cannot lose or duplicate one.

The system has an assistant that operates accounts in natural language: “withdraw 250 dollars”, “move 80 to my savings”. A language model deciding money movements is exactly the kind of thing that cannot go right by accident.

Filtering the model’s output — inspecting what it asks for and blocking the dangerous cases — which is the usual answer and loses because it is a denylist: it protects against what you thought of, and prompt injection consists precisely of what you did not think of. And a pending table of my own with a cron to clear expired rows, which works but adds a process that can fail silently.

The hold is expired by the ledger itself when its lifetime passes, so there is no cleanup process: the background job that could fall over does not exist. Prompt injection stops mattering, because the worst an attacker achieves is preparing an operation the account holder has to confirm with their own session. The cost is that the conversation has one more step: the assistant never completes anything on its own, and that is felt in the interface.

Every message to the assistant costs real money. A public demo with open registration is an invitation for someone to spend my budget for me.

Reading the counter, comparing in Go, and writing the new value: the classic race, and with several concurrent requests the ceiling is exceeded. And a per-IP rate limit, which measures the wrong thing — I do not care how many requests someone makes, I care how much they cost.

The budget holds under concurrency because the check and the increment are the same operation, and a test running with -race fires goroutines against a small ceiling to prove it. Because spend is reserved with a high estimate and settled with the real cost, the interface has four states instead of a boolean, and says which engine answered. A rules-based provider also exists, so the application works with an empty API key. The cost is that “is the assistant available?” stopped having a yes-or-no answer.