This is quite common in Banking system, since they handle money, the concept of rollback is really dangerous, it is always better have a compensating action, because it retain more information. Each movement should be recorded, and if a movement should be cancelled for some reason (the ATM machine broke and cannot give you money), you can only compensate.

What if the compensating action transaction failed and the not withdrawn debit was not credited back to your account? When my ATM could not give me the withdrawn money, because it did not have a fitting set of bills, it always told me so without (visibly) performing a debit on my account.

I guess all banks have a concept of "transaction of transactions", the rollback is a series of transactions of compensation actions

Some ATM/banks with slow internet connections for small amounts of money don't even check if You have the money on Your account at this current time (there is a significant delay in updating total amount).

Compensationg actions is transactions for occasionally connected systems like ATMs.

I hope your wifes' pin code is not 3581...

Of course, the action and the compensating action are both written inside of a transaction. There are two transactions here, not one.

This decision surely wasn't purely technical. When it comes to distributed state (like in ATM machines) technical decisions can have business implications.

That is very interesting. I'm not sure how I feel about that. On one hand you would except such an important function to use transactions but on the other it is nice to see where the failure occurred and that the funds were credited back. At least if the proper trail is there it should be simple to resolve any discrepancies.

ATMs have been one of Udi Dahan's example's of SOA for years, I wouldn't even be surprised if he or one of his (or Greg Young's) eventual consistency proteges had designed the system.

The back-of-the-envelope idea is that for many systems it is more important to get immediate feedback and retain ALL history of ALL user interactions than for the entire distributed system to be constantly consistent. When designing a cqrs messaging system you consider the failure scenarios in a bounded context and treat them explicitly. Yes it is possible that the recovery action has an error as well, you can plan for that, and make it a business person's decision how far down that rabbit hole you want to go. In the case where 3 orthogonal, non-dependent operations fail in a row, the bank might decide it'll take its chances with an angry customer.

The thing is that even DTC is subject to CAP theorem, and cqrs (which again, is applied only within a bounded context, not necessarily system wide) forces you to explicitly deal with those limitations.

If I'm not mistaken, ATMs have a paper trail as a form of low-tech audit log that can be ultimately matched to the records. I don't think using correction fluid is an option :-)

You and your wife are lucky!

Last year I went to Malaysia and my friend whom I was traveling with, withdrew about $500 AUD from the ATM... No money came out...

The money was taken from the bank account in Australia, but the bank in KL had absolutely no record of the transaction at all and tried to dispute that the ATM transaction did not take place.

It took about 3 weeks to get the money back...

The scenario you described, I wish MORE banks implemented because clearly it works!

I agree that this is interesting in that a record was made even though it failed. I believe that was your point in the first place. :-)

Since it did make it into the accounting; not deleting the transaction (debit/credit) is normal procedure for accounting situations. It's known as T Accounts. http://www.cliffsnotes.com/study_guide/T-Accounts.topicArticleId-21081,articleId-21009.html

One of my first systems I wrote required that every debit transaction type had an opposite credit transaction type.

Ayende, we all know you were quite upset with all the women out there and instead set out to write your own wife as a computer A.I. When can we expect a RhinoWife Profiler?

Compensating transactions are also superior if there is any degree of async/parallel 'business process' (particularly if there is Human Workflow-centric exception handling). They are also good if there are multiple external partner systems involved that you have no control over; it's a looser dependency. There is no silver bullet though; compensation can become arbitrarily complex very quickly as the transaction nesting level increases. At a certain level of complexity, automatic recovery is no longer manageable, so it is common to use HWF-centric exception processes that 'adjudicate' the compensation process.

Pat Helland wrote about this a few years back "Accountants don't use erasers" http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx

Regardless of whether this is a good design decision or not, banks should not be held up as a good example to follow.

The worst code I've ever seen lies in financial systems.

DTC's are expensive ...

In any case there were probably 25 systems in the chain going from ATM to Account where it could have failed. Not all of them can be involved in a coordinated transaction. Both from a practical and technical point of view.

Unfortunately many banking and financial systems still have their underpinnings stuck in the dim and distant past (70's). The APACS protocol used in the UK was devised for use with modems. It's been adapted and butchered for different types of transmission and bank transaction types. It has to be one of the most antiquated protocols there has ever been yet their is no desire to change it for something more flexible and expressive.

More worryingly many of the banking protocols have no inbuilt form of security or message authentication. They are wholly reliant upon the use of private or closed networks.

Interestingly you have the same auth code, often banking terminals (ATMs, PEDs etc) will reuse the same terminal message number for a subsequent transaction to indicate that the transaction reverses the previous one.

As Flukus said, banking systems are poor examples of how something should be done.

I think the problem is that the word transaction is a loaded one for database developers. ATM transactions involve physical interactions which can't be rolled back (giving money to a person.) Rolling back a database transaction during a failure doesn't rollback the entire transaction (the money doesn't dissapear from a theif's pocket.)

Additionally, you're making the assumption that a transaction isn't occurring at the database level by what you see on your bank ledger. It's entirely possible that the ledger is constructed from reports produced by the ATM, and the appearance of this as a credit/debit pair is due to constraints of your bank ledger, not the ATM's transaction system. It's also possible that the ledger appears as it does because analysis has shown that (most) customers react better to seeing a credit/debit pair on their ledger than another means.

In either case, it's dangerous to assume that something is wrong, until you have actual evidence.I don't know how many times wild assumptions have come back to bite me as a professional...

Maybe your wife just got robbed. Years ago in Mexico, there was this device that bad guys put over the ATM's that look like the original thing but puts your money in a secret compartment when asked for it. Then the bad guys came and remove the "mask" and took your money. The bank could swear that everything went just fine but ...

There's a lot of talk here about transactions and what not, but it's really a lot simpler than that. From the banks perspective, they don't want to give out money unless it's been recorded. Consider what might happen if you went through the process, the machine belched out it's cash, and before it could be recorded, the power went out or something broke, or the ATM blew up or whatever.. Suddenly, you've disbursed cash, but have no record of it.

So from the banks perspective, it needs to record the transaction, and THEN give out the money. If the disburser mechanism is broken, then it won't know until it tries to disburse the cash.

It's simply far more important that a record exists before any cash leaves the machine. And since, once a transaction is recorded, it cannot be unrecorded, a correction must be made. It has nothing whatsoever to do with transactions. It's all about protecting the cash.