Hacker News Reader

I currently work on a client accounting system at a large bank, and have worked at another large bank previously.

While what you described may happen somewhere, the pattern in banking systems that I've seen is pretty straightforward and simple to reason about: a cash flow produces two ledger entries within a transaction and is committed with no concept of distributed rollback.

If there are problems with some sort of subsequent step (e.g. the actual dispensing of cash in ATM or invalid routing instructions in a cross-border payment), the original cash flow is reversed with a reversal of the original two ledger entries -- which is precisely what Ayende saw on his statement.

If a correction is also required in addition to the reversal (perhaps SOME of money was dispensed before an ATM loses power), the correction will be encapsulated with another pair of ledger entries.

(These various cash flows will then typically be placed on a payment bus for further processing by various other systems that perform recon, liquidity management, etc. Again, there is no distributed transaction, just simple double-entry accounting and straightforward transactional message queues.)

> Actually they don't need to use transactions at all in accounting. All they need is a debit history and a credit history.

If by "debit history" and "credit history" you're thinking of how your bank transactions are recorded, then you may wish to look into the concept of accrual accounting.

Merely tracking cash in and out doesn't give you a full view of what the business is up to.

> accept that some figures won't reflect exactly the reality of the balance, since some compensations are done immediately (automatically) while others are performed, manually, days or week later.

Well good luck with selling your "eventually consistent" accounting system.

While I would prefer if accounting systems could be improved to record and aggregate uncertainty for those places where values entered are based on what is realistically an estimation rule (eg depreciation, stock valuation rules etc), the fact is that all such rules are stated as part of the reports. Within that framework, you report as correctly as possible to the cent or better.

Otherwise bad things happen. Accountants lose their charters. Executives go to jail. That sort of thing.

Serious business is ... serious business.

Isn't accrual accounting the use of an account to log transactions at the time of sale rather than at the time of payment? If so the same technicalities apply, you can log your credits and debits in different accounts, no need for ACID transactions here, unless my experience in this area is flawed.

> Well good luck with selling your "eventually consistent" accounting system.

There's a reason why "eventually consistent" works in accounting, and that's the cut-off time. You don't require from your data to be consistent at every instant, but rather require that your accounting be guaranteed consistent at cut-off time, because that's the data that you base your reporting on. One way to guarantee that is to use only ACID transactions, but it's only one of many ways, and it has flaws (that might or might not be blocking depending on how distributed your architecture is).

> you can log your credits and debits in different accounts, no need for ACID transactions here,

Um, yes. There is. There totally is.

There's a reason ACID is illustrated with examples based on debiting one account and crediting another at what is a logically simultaneous instance (Atomicity).

Because if you do one and not the other, your accounts are now Wrong-with-a-capital-W-for-legal-consequences (Consistency).

We need these to happen in some sort of order, so we pretend only one such entry happens at a time (Isolation).

It would also be jolly nice if we didn't lose the records (Durability) every time the RAM lost its juice.

> You don't require from your data to be consistent at every instant

Again: yes. You do. That's literally the entire purpose of double-entry bookkeeping: to guarantee that the books are always consistent.

Otherwise bad things happen. Accountants lose their charters. Executives go to jail. That sort of thing.

Funnily enough, "Enron" was the first name that sprang to mind whilst reading comment.

That was due to bad wording on my part, my bad.

I meant that one should accept that at any random moment the data might be inconsistent with the reality, but after the cut-off time the data for the previous period is guaranteed to be consistent.

there are multiple ways to achieve transactions. locking on the server is one, but it is not necessary.

Optimistic Concurrency Control is another way of achieving this where transaction is kept on the client and posted to the server when transaction is complete without locks.

The problem with just keeping a debit/credit history is that a session can die or go corrupt at any moment, potentially leaving an incorrect transaction leg on the server. A system to detect such cases and back them out would be more complex than using transactions in the first place.