Coffee Shops Do Use Two-Phase Commit


The article, Coffee Shops do Not Use Two-Phase Commit is, total rubish. Well, OK, maybe not total, but the central premiss that Starbucks does not use 2-phase commit is nonsense. This artical represents a counter argument and I will explain how and where Startbucks do use two-phase commit.

But before we get started I should mention that I come across the Starbucks artical on various website pointing out why NoSQL databases which don't support transaction arn't such a bad thing (e.g. Couchbase and MongoDB). Well if you're dealing with valuable cross entity data (such as financial data), then not having transactions is pritty much like sucking on a cyanide stick and not having a doctor. 

So after pondering what Gregor was saying I decided to go to my local Starbucks to take a look at whats acually going on, and found that Starbucks and all coffee shops do use Two-Phase commit.

Gregor's Problem

The problem with Gregor’s toung in cheek description of the transactional aspects of a coffee shop is that he’s incorrectly identified the processing model and the bounaries of the transactions.

The article assumes the transaction ends when the coffee is in your hand. However, this is wrong. The process of buying a coffee is in fact a two stage transaction, and is typical of many puchasing and delivery senarios.

The first part, and most important, is concerned with taking an order and payment. This part does use two-phase commit as will be explained. This transaction sets up and establishes the terms of delivery. In other words, once payment has been processed a contract of delivery exists between you and Starbucks.

The fullfilling of that contract is the second transaction. 

Starbucks Workflow

Note that as with any system where you pay up-front for a product, a contract is established based on the terms of your payment. This is true whether you are buying products from Amazon, putting a down payment on a car, or buying a coffee from Starbucks.

The business model at Starbucks is that you pre-pay for the products, and then they will deliver them to you.

Placing the Order and Two-Phase Commit

The two-phase commit transaction is made up of a prepare (or voting) phase, and a commit phase.

Phase 1

During the voting phase the coordinator (which in the case of Starbucks is the cashier), attempts to get all parties to agree that the order can be fulfilled. You can see this in action when you order muliple items from the cashier at Starbucks.

The cashier will take the order and instruct the staff what to do (tell another member of staff what cake to get, and the barista what coffee to make, etc). Only once all cohorts are in agreement is the order confirmed and payment taken.

Phase 2

Phase 2 is the commit phase. The commit phase is sealed by taking payment. Note, as mentioned earlier that once payment has been taken, Starbucks is legally bound to make good on that order.

Once all the workers are satisfied, the payment is taken and that complete the two-phase commit transaction - a contract is established, Starbucks have their money, and you have less money and no goods. But what you do have is the contract.

Now we just wait for the delivery of goods to satify the contract.

Delivery of Goods

Note that the delivery of goods is not part of the transaction, but a direct consiquence of the transaction.

This, as noted earlier, is the same model employed by Amazon and all other pay-now-get-latter business models.

BTW, if you are thinking about starting up a business this is a good model to get going wtih and establishing the straight of your market.

Concurrency and Serialization

Gregor points out correctly the oppertunties for concurrency in delivering the coffee. However, oppertunities for concurrency are  limited in the Starbucks business model. That limitation is due to the number of tills.

A True Concurrent Model

In European cafes one way to get greater throughput is to use table service for taking orders and taking payments. That way the whole system is concurrent. Each member of staff has a notebook for taking orders, and other members of staff have purses for taking payments. At busy times you just employ more staff.

This is more akin to Concurrent Messaging Systems such as Java's JMS which provide a distributed and loosely coupled, reliable and asynchronous service. Note however, that even in this model transactions play an important part.

For example, when the waiter takes the order they often follow the characteristic principles of database transactions. The taking of the order is Atomic in that it is taken or not taken, it is Consistant in that once the order has been taken the entire system moves to a new state, it is Isolated in that other orders do not interfer with your order, and it is Durable in that the order is written down on some durable medium (such as a note pad). So we have the normal database ACID properties.

BTW, on the issue of Isolation. If someone puts in an order for something that has just sold out does not mean that the orders are not isolated, it just means the system has move into an error condition, but all is still consistant. Just that someone's order will have to be rolled back.

Systems such as we've described above do not use two-phase commit, and do not have inherent error correction. As menstioned, orders can be placed for products that have already sold out, and customers can products simply by leaving the premisses before paying. 

Error Correction

Now back to Starbucks and Two-Phase Commit.

At Starbucks the normal error correction algorithms are employed as they are in all two-phase commit transaction processing.

Errors During the Voting Phase

If during the voting phase any of the cohorts indicate then cannot fulfil the order then the whole transactions rolled back and the customer is given a second option (retry).

Commit Phase

If anything were to fail during the commit phase, the same error correction takes place - the casheers decides what to do and coordinates that with the various workers and the customer. So if the customer can not pay, then a full roll back is put in motion. If the coffee machine breaks down, the customer is given a second option (retry).

Post Commit Phase

However, if the payment has been made and then the coffee machine breaks down, then a new trascation has to be created to undo all state setup by the first trasaction. In normal database transaction this is often refered to as "undo the transaction using the delta logs". In starbucks it's know as giveing a refund using the till receipt.


If you're sat in Starbucks now watching what is going on, and what you are seeing is not matching my nice an clean description above, that is because the staff are optimising. And they are optimising using typical and well known two-phase commit optimization techniques.

Presume Commit

The first and most obvious optimization is Presume Commit. The Presume Commit optimization assumes that all phase 1 votes will be positive and once the order is vocalized (or written on the cups) the various workers proceed as if they will get a commit message. Most of the time this works. The weak point is if the customer can't pay, but with the increase in throughput and the fact that the vast majority of customers can pay, coupled with the fact that coffee in terms of its raw ingredients is cheap, then this optimization pays off.

Dynamic Two-Phase Commit

This optimization reduces the role of the coordinator. It assumes an Yes Commit is in place, and all workers will start putting together the order as it is being taken without the cashier having to coordinate. So in computer science terms all the processors will propagate Yes Votes as soon as they are aware of the action to perform and will start performing that action. In this situation the coordinator (cashier) only needs to propagate Abort messages when things go wrong. Again, this is a good when in a most-trasaction-will-suceeds-and-even-if-they-dont-then-the-cost-is-no-big-deal environment.


In summary, Gregor's statement that coffee shops do not use two-phase commit was just wrong. However, his insight to how coordination and correction works in an asynchronous environment was spot on, and this includes a distributed transactional two-phase commit environment. Starbucks, Amazon, and any other situation where you pay for goods or a service before receiving them will use a version of two-phase commit - check everything is ready, and then commit the order.

The key to understanding this is knowing when a transaction starts and when it ends. To give one simpler example; when you pay money into your bank, the transaction will start when you give the money and payslip to the cashier, and ends when she hands you the receipt. It does not end when you get your monthly statement or when you close your account.

These semantics are intuitive to us as human beings and it is why we feel bit uncomfortable when using a bank's self-service pay-in machines. Using these macines you just drop in an envelope containing your cash and a payment slip and then just walk away - with no receipt or evidence of what you have done (i.e. no commit so you don't know whether your payment has been durable).

Summary 2 - NoSQL Databases

So NoSQL databases are being touted around as being "web-scale" because they work really fast. In fact, the reason why they work fast is because most of them do not support transactions. In other words, when you post data to them you have no idea whether that data has been persisted or not. You do not know if your data is safe.

Transactional support is slow, and the reason why it is slow is because of all the fault tolerance software designed to ensure that when your transaction is complete then the database is safe, consistent, and permanently stored.

If you care about your data, and most people really really care about financial data, then you need transactions. If your system needs higher throughput then you need faster or more hardware.

One thing you don't do is get rid of transactions because then you really are sucking on a cyanide stick without a doctor.

Check out this video which explains all you need to know about web-scale NoSql databases.




Add comment