Queued Transactions

Persistent message queues provide the basis for queued transactions.
This example illustrates an atomic transfer of money between accounts in different banks even
though all transactions are local (there are no distributed transactions).

Bank C has a local database containing

Persistent message queue Q1 holding messages to be delivered to Bank A; and

An integer NQ1 which records the number of messages which have been processed so far from Q1; and

The balance A1 on an account managed by bank A

Bank B has a local database containing

An integer NQ2 which records the number of messages which have been processed so far from Q2; and

The balance A2 on an account managed by bank B

Initially suppose NQ1 = NQ2 = 0 and A1 = A1 = $100.

Bank C wants to transfer $10 from account A1 to account A2. This is achieved with an atomic transaction on its local database:

Insert message to deduct $10 from account A1 into Q1; and

Insert message to add $10 to account A2 into Q2.

Some time later bank A receives the message to deduct $10 from account A1. Bank A then applies an atomic transaction on its local database:

NQ1 = 1 and

A1 = $90

Some time later bank B receives the message to add $10 to account A2. Bank B then applies a atomic transaction on its local database:

NQ2 = 1 and

A2 = $110

It is possible to avoid a negative balance:
Introduce two holding accounts A3,A4 on C.
C transfers A1 to local A3.
A transfers from A3 to A4.
When C finds money in A4 it transfers to A2.

ATMs are designed to have a normal case behaviour and a partition mode behaviour.
In partition mode availability is chosen over consistency.
The issue is you might withdraw more money than you have so the end result might be
consistent, but negative, which can’t be compensated for by asking for the money back,
so instead, the bank will change you an overdraft penalty.