The blockchain is inspiring a new generation of financial services innovation, but blockchain technology is often pressed into service when it’s not the best fit for requirements, for instance, as a distributed ledger. A distributed ledger allows participants at different sites to maintain shared transaction logs. It can function as the backbone for funds transfer clearing houses or for any other dataset that needs to keep account balances consistent across replicas.

Blockchains typically aren’t optimized for transaction rate. Instead they focus on enforcing trust through proof of work. Adding participants does not spread the work out, instead it increases the total amount of work each must do. Most distributed ledgers don’t need to run among untrusted parties, so the blockchain is a poor fit.


When participants are trusted, an ACID compliant distributed database offers a simpler solution for a scalable distributed ledger. Fauna’s CTO Matt Freels gives an in-depth look at a ledger use case in this article about transactions. This blog post is hands-on with an example pet store application.

I’ve created a demo app to show how simple transaction programming can be. Visit the app and drag and drop some animals to buy and sell them. You’ll see each player’s balance update as you run transactions, and that it’s impossible to overdraft. The data is hosted in FaunaDB Serverless Cloud, with replica sites around the world, all updated consistently.

Hello Ledger

Keep reading to install your own copy of the app and explore the transaction queries. Here are the steps to hello world.

Install the demo app

git clone https://github.com/fauna/animal-exchange
cd animal-exchange
npm install

Launch the demo app

npm start


Now you are up and running and enjoying the app locally. If you’d like to modify the code or the schema, full instructions for developing on the app are in the readme.

Look at the code.

Since you are here for the transactions, let’s look at one important query. Here are all the queries, and here is the code that defines the schema.

And here is the core of the transaction to purchase an item (see the code for the entire transaction):

// check balance
    q.If(q.LT(q.Var("buyerBalance"), q.Var("itemPrice")),
      "purchase failed: insufficient funds",
      // all clear! record the purchase, update the buyer, seller and item.
      q.Do(
        q.Create(q.Class("purchases"), {
          data : {
            item : q.Select("ref", q.Var("item")),
            price : q.Var("itemPrice"),
            buyer : q.Select("ref", q.Var("buyer")),
            seller : q.Select("ref", q.Var("seller"))
          }
        }),
        q.Update(q.Select("ref", q.Var("buyer")), {
          data : {
            credits : q.Subtract(q.Var("buyerBalance"), q.Var("itemPrice"))
          }
        }),
        q.Update(q.Select("ref", q.Var("seller")), {
          data : {
            credits : q.Add(q.Select(["data", "credits"], q.Var("seller")), q.Var("itemPrice"))
          }
        }),
        q.Update(q.Select("ref", q.Var("item")), {
          data : {
            owner : q.Select("ref", q.Var("buyer")),
            for_sale : false
          }
        }),
        "purchase success"
      )

Selling an item involves reading and updating a handful of database records. Without ACID transactions, if any one of these operations were to fail, it could leave the database in an inconsistent state. When you are buying and selling, you have to be able to trust your database.

The transaction includes these operations:

  • Check the credit balance of the purchasing player to ensure they have available funds.
  • Check that the item is for sale.
  • Update the balances of the selling player and the purchasing player.
  • Update the item with the new owner.
  • Write a purchase record.

FaunaDB’s ACID properties mean that if any one of these operations fails, for instance because the player is making multiple trades at the same time and exceeds their balance, the entire transaction must fail. This also holds true in cases of hardware or network failure. So you know that any data you read or write to FaunaDB is consistent, taking the guesswork out of writing correct applications.

For more detail about our consistency model and what that means for applications, check out Matt’s article.

  1. Read our White Paper

    Explore the motivations and technical design of FaunaDB in our white paper.

    Get the White Paper

Stay up to date with Fauna

Subscribe to our Blog and get notifications when we publish new content.

Successfully registered your email. Stay tuned for more updates from Fauna!