2

There are points of failure:

  1. ATM gives money then send a deduction request to it's bank. What happens, if the request will fail? the user got the money but his account hasn't been deducted - fail.
  2. ATM send a deduction request to it's bank, bank deduct the value, send a request back to ATM, the request fail (disappear). the user was deducted but hasn't got his money - fail

Who knows the solution used in real life?

Andy
  • 2,003
  • 16
  • 22
arminvanbuuren
  • 33
  • 5
  • google 'two-phase commit' or 'distributed commit'. – Aganju Sep 12 '18 at 23:30
  • 1
    I guess this is a special case, it's possible just hold the value at the bank side until confirmation of failure or dispense will come from ATM. It's close to distributed commit but I guess this case could be handled simplier – arminvanbuuren Sep 12 '18 at 23:44
  • I agree with @arminvanbuuren in that it kind of works (albeit quicker) how credit transactions work. The amount is "held" when the transaction is initiated, and the bank gives the all clear. Then after the cash is physically dispensed, the clearing transaction flags the initial one as successful, and the held amount should be released to whoever operates the ATM. – Daniel Park Sep 13 '18 at 00:10
  • 1
    ATMs can also be audited after the fact to reconcile what they think was dispensed for what transactions, which means the banks can credit withdrawls that didn't actually succeed. – Blrfl Sep 13 '18 at 02:10
  • Solution #2. If it was #1 the bank would have to figure out who to complain to. With solution #2 there's a built in guarantee of honesty and the money is still in the machine to give to the person the next morning. Have [a look inside](https://youtu.be/DnWaonrNj9s). – Rob Sep 13 '18 at 04:23
  • LOL I'm so surprised nobody knows this commonest case... I browsed a lot of web pages and really no answer... I think the bank hold the money (not deduct) until success or fail confirmation comes from ATM. If ATM reset the confirmation will come later and the bank release/deduct the funds. Another process at the bank ping all ATMs, and alerts the crew about accidents. (all above is my guess) – arminvanbuuren Sep 13 '18 at 08:55

2 Answers2

7

Disclaimer: For the following part, I'm saying most, because I obviously don't have experience with all banking systems.

Just like any system which needs to be really fast, even banks are eventually consistent. When you're implementing such system, you really want it to be online as much as possible. Any possible downtime will hurt your business, because you're delaying the customer in whichever situation they currently are. And believe me, slowly responding banking system is a really awful experience also for retailers. It hurts everyone.

To stay as available and fast as possible, most ATMs and/or card terminals don't verify your balance and process the transaction against the master in real time. With the amount of transactions, that would flood the system.

The owners of banks know that, the majority of requests to withdraw money from ATM or to issue a card transaction are going to succeed. Because of this, when you do actually want to withdraw money from ATM, the machine pings the bank's very quick and scalable read model to very quickly check if you have the desired amount or not. Know that this ping is done on a replica and thus may not be in real-time sync with the master.

Once the ping is done and your status is verified, the ATM notes that you have made a withdrawal and dispenses the money. Every configured period the ATM then collects all withdrawals made and sends them to appropriate authorities.

Some ATMs might be (and usually are) more complex, remember some information about your account from the card, so that they don't have to ping the bank every time. Thanks to this, the ATM alone usually prevents you from withdrawing $500 and $500 right after when your account would only contain e.g. $501 - in this case the first withdrawal is fine, the second is not, because the ATM remembers you had $501, have withdrawn $500 so your theoretical balance is $1. Obviously, if the ATM is one of the dumber ones which ping banking association every time, the replica is still likely to reply with $501 even on the second withdrawal and even the second withdrawal will be allowed. But this is still not a problem.

Because banks actually don't mind you to go into negative balance, they even allow these temporary hiccups and implement a reporting system which notifies administrators and support in a case when someone's balance becomes negative. This in turn may trigger other processes, such as starting to bill your for the time of having a negative account balance,...

While banking might seem really strict and feels like every single operation must be consistent, availability is a much more important aspect when it comes to banking, therefore banks are programmed that way.

To answer your questions directly:

ATM gives money then send a deduction request to it's bank. What happens, if the request will fail? the user got the money but his account hasn't been deducted - fail.

To prevent this problem, the ATMs are implemented to record both withdrawal request (containing information about how much you want to withdraw) and event about withdrawal completion.

When the WithdrawalRequested event is stored, the ATM starts giving you the money. If it dies right after giving you the money but before storing the WithdrawalCompleted event, this is not a problem.

  1. After a reboot the ATM will in some way sum all made successful withdrawals, subtract the sum value from original amount of money inserted into the ATM,
  2. The ATM will find inconsistency, that it's in fact missing $500, find all entities without WithdrawalCompleted event, and if there's an incomplete request it [ATM] will simply complete it.

Ad 2. If the ATM is unable to find a matching withdrawal, it sends a report to authorities that this has happened and it will have to be investigated.

Now, if you do request withdrawal and the ATM dies before even recording the WithdrawalRequested event, this is not a problem, simply nothing will happen. But if the ATM dies between storing WithdrawalRequested and actually giving you money, as before, after reboot measurements need to be made that the request is not actually sent to authorities, once again by verifying the current state of money in the ATM - in this case the money would match amount of sum of completed withdrawals subtracted from original amount of funds and the request will be simply discarded (still possibly notifying someone that the problem has occurred).

ATM send a deduction request to it's bank, bank deduct the value, send a request back to ATM, the request fail (disappear). the user was deducted but hasn't got his money - fail

This situation will never happen since the ATMs do not issue the command before dispensing the money but after.

Andy
  • 10,238
  • 4
  • 25
  • 50
  • is your point: its possible to withdraw more money, than you have, but banks appreciate this, because they will caught you later and punish with huge %% for overdraft? – arminvanbuuren Sep 13 '18 at 19:18
  • 2
    @arminvanbuuren, no. My point is that banks don't care if you actually are able to withdraw more money than you really have, because banks know how to get the money back anyway. As mentioned, because of that strong consistency on those operations is not required. – Andy Sep 13 '18 at 19:20
  • ok, thank you for so detailed answer: one little case you forgot to clarify: 1) WithdrawalRequested stored, money dispensed, WithdrawalCompleted stored. Then what? send a so called DeductionRequest to the bank? But what if the DeductionRequest dies on his way? – arminvanbuuren Sep 13 '18 at 19:29
  • 1
    @arminvanbuuren, that's more of a networking issue and is resolved by having a service bus possible of message/request deduplication - done by each message/request being uniquely identified. If the ATM's request cannot be processed (the ATM receives an error during the request), it [the request] is simply repeated and it's up to the consumer to know such message is not to be processed again. Udi Dahan has a great talk on this. I recommend you to [**check it out**](https://vimeo.com/111998645). – Andy Sep 13 '18 at 19:36
  • oh, thanks a lot, i'm eager to watch it right now! and what if ATM dies right before send DeductionRequest ? After reboot it will check consistency of WithdrawalRequested + WithdrawalCompleted = DeductionRequest ? So in case of DeductionRequest absence send it, i guess? – arminvanbuuren Sep 13 '18 at 19:40
  • 1
    As you will see in the talk, @arminvanbuuren, part of the messaging mechanism is to also store information about requests to be sent, along with the message id. It the ATM dies, it will simply pull the requests out of the storage and repeat them and have the consumer deal with possible duplication issue. – Andy Sep 13 '18 at 19:42
0

Normally, this isn't a transaction between the customer and the bank via the ATM, but rather two separate transactions, one between the customer and the ATM, the other between the ATM and the bank. (Note when using your card abroad, it might not even be possible to reach the bank from the ATM).

One step in that transaction might be the ATM querying the bank account for coverage. Depending on where you are and when you use the ATM, this step might be omitted. The ATM will, however, not give you any money before it could store a temporary transaction to its server (which is not necessarily "the bank").

Once the transaction is completely finished between customer and ATM, the ATM (or, rather, its bank server) will simply send a message to your bank, deducting the money and confirming that transaction.

In case the temporary transaction cannot be finished between the ATM and its back-end server, (ATM dies or data link breaks in exactly this moment), the ATM will shut down, probably eat your card and wait for someone to manually intervene. This is simple, because you can search for such unfinished (timed-out) transactions frequently on the back-end. Whether the customer has received their money or not, in this case, is something only the local ATM log knows. If there's no proof you actually received your money, the bank has to write off this amount. In my country, ATMs have to generate local paper printouts for logging.

tofro
  • 891
  • 6
  • 10
  • thank you, so if the ATM dies immediately after money dispense the user can go to another ATM and dispense the money again? – arminvanbuuren Sep 13 '18 at 18:44
  • Added some explanation - It's important to understand an ATM doesn't necessarily talk to *your bank*, but to its own server - And when I'm saying "ATM", I'm not talking about the roadside box only, but rather the system consisting of the money box and a central server behind it - And it will store a temporary transaction there before it hands you any money, finishing that transaction if that succeeded – tofro Sep 13 '18 at 18:50
  • ok, so we came back to the question essence: what will happen first (1) money dispense or (2) "store a temporary transaction" ? What will happen, if 1 or 2 completes and ATM (money box) immediately die? – arminvanbuuren Sep 13 '18 at 18:58
  • The temporary transaction always happens first - Any unfinished transaction will then lead to a manual investigation from the ATM's local transaction log (has the customer got their money or not?) – tofro Sep 13 '18 at 18:59
  • ok, i see "The temporary transaction" - is the kind of holding money without deduction, thanks – arminvanbuuren Sep 13 '18 at 19:02
  • In case the ATM cannot finish such a temporary transaction, it will normally shut down and go out of service (probably even eating your card in that process), before you ask – tofro Sep 13 '18 at 19:04
  • yes, but my question was: what if the first step completed (for your case "The temporary transaction") and then ATM immediately die (the user haven't got his money)? – arminvanbuuren Sep 13 '18 at 19:06