Banking Example Again

I was reading through this yesterday on my way out of London. Go on take a minute and read it.

I do find it funny that the bitcoin exchanges were taken down by such things but the article is pretty ridiculous in how it presents its problem/solution. Banks don’t actually work as described in this post. There is not a column “balance” in an account table as presented unless the developers just had no clue what they were doing.

mybalance ="account-number") newbalance = mybalance - amount database.write("account-number", newbalance) dispense_cash(amount) // or send bitcoins to customer - See more at:

This is absurd your balance while perhaps being denormalized on your account is really the result of an equation (summation of the value of your transactions). All of these problems discussed would just go away if the system had been designed to record a journal properly (and as the journal is append only most other issues would go away).

I have always hated that the typical example of distributed transactions is transfering between two accounts. Banks don’t work this way!


  1. James McMahon
    Posted April 10, 2014 at 11:37 pm | Permalink | Reply

    It doesn’t matter whether the banks keep track of a balance or a log of transactions. As long as the underlying engine is eventually consistent, they are open to the kinds of problems cited in the article.

    • Posted April 11, 2014 at 7:06 am | Permalink | Reply

      This is not true. In the case cited a transaction is lost. With an append to a journal neither transaction gets lost.


      t1 read $50
      t2 read $50
      t1 -= $10
      t2 -= $25
      t2 update $25
      t1 update $40

      $25 is lost.

      t1 insert $10 deduction
      t2 insert $25 deduction

      neither is lost.

      Banks are at their core eventually consistent (its even in their business models).


      • Jason H.
        Posted April 28, 2015 at 11:16 pm | Permalink

        We seem to have existence proof that at least two Bitcoin banks run precisely in the manner cited by the original article, and not the idealized way you mention.

        Even with a journal, the outcome depends on the conflict resolution strategy used in the database. Cassandra’s default of “last writer wins” strategy, for instance, would still lead to the exact same problem.

        The bottom line, made in the article, is that it is very difficult to perform the accounting correctly on top of a data store that provides eventual consistency.

      • Posted April 29, 2015 at 12:53 am | Permalink

        If you know a bit coin bank that when you transfer money to me it immediately books it let me know which one that is… The block chain takes +-10 minutes to clear it.

  2. Posted April 11, 2014 at 10:11 am | Permalink | Reply

    Totally agree. Running distributed transactions between banks would be ridiculous.There’s no way a bank is going to allow third parties to issue transactions against it’s databases.
    Ever heard of the SWIFT network? Funds are moved out of the payer’s account, are in neither account while traveling over the SWIFT network, then are moved into the payee’s account. Any issues along the way are dealt with by compensating actions. Sometimes, instead of rolling back, there are options to roll forward (like a bank charging a fee for a failed transfer)

    • Posted April 11, 2014 at 10:13 am | Permalink | Reply

      There are also loads of intermediaries such as government clearing houses.

    • chrisbednarski
      Posted April 11, 2014 at 10:44 am | Permalink | Reply

      Also, because of eventual consistency, debit accounts can (and sometimes will) go into negative balance. This is undesired, however, perfectly normal.

      • Posted December 3, 2014 at 8:21 pm | Permalink

        Undesired? At $25 or $50 a pop, it’s typically one of the most desirable fees on an account’s terms. The only thing that’s undesirable is when it doesn’t get remedied quickly enough or is negative by a significant amount. That’s usually controlled by tying it to a small credit line that allows them to charge additional fees and interest.

        I mean …yeah, nobody likes to be in arrears, but it’s not like banks haven’t figured out that eventual consistency is highly profitable 🙂

      • Jason H.
        Posted April 29, 2015 at 3:16 am | Permalink

        It’s not as simple as that: banks typically have a “monotonicity” requirement. Once posted, neither the bank nor the users want to see deposits and withdrawals suddenly disappear. Eventually consistent data stores do not guarantee monotonicity. Rest assured that every customer who sees her deposit appear and reappear will immediately get on the phone with support, increasing costs by 1000x. Worse, a bank officer might issue a compensating transaction for a deposit/withdrawal that eventual consistency makes temporarily unavailable. So, all of you code warriors who think you can build a bank on an EC data store, think again.

      • Posted April 29, 2015 at 11:00 am | Permalink


        “Eventually consistent data stores do not guarantee monotonicity. ”

        There are multiple types of eventual consistency that are commonly lumped together. Google strong eventual consistency you can certainly build a bank on an eventually consistent data model. Btw do you remember those things called cheques (or maybe you live in the US and still use them). Retail banking at a conceptual level has been based on eventual consistency and risk mitigation for centuries. Consensus was vastly too expensive to try to maintain.

        Your example with a compensating transaction is better handled through a causal requirement than saying “lets make everything consistent, since it would be unavailable anyways!”. Specify this as a dependency on the compensating action. These are not new fangled ideas or tradeoffs associated.

        What this has to do with the original post is getting really questionable though. Also why do you feel the need to troll people a year after they commented?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: