Your Coffee Shop Doesn’t Use Two-Phase Commit (Starbucks async processing model)

When I was in college as an undergrad, I worked at a local dive bar with a grill. Being a CS guy, and working with a couple other CS guys, we had a lot of fun with this same idea. When we worked the kitchen we would apply our understanding of queueing to great effect. We would play with different algorithms, analyze the bottlenecks presented by the various stations, optimize on expected workloads and so on. When some of the younger people also in CS would be taking the relevant classes, we would challenge them or help them (depending the person's skill level and needs) by showing them the applications in terms of the kitchen. It was pretty awesome. I think it really helped us get an intuitive feel for various aspects of decoupled queue based systems -- sometimes I still flash to the kitchen experience when figuring out workflows, and sometimes my early sketches of a system are laid out like the kitchen we worked in.

Some cool lessons from this:

* If you just look at the infrastructure, there is obviously one optimal way to do it, however if you look at the people doing each task at a station, this may change. We would abstract this out in our systems thinking to imagine various people as various systems or processing algorithms with different runtimes, and which we had no control over. This had strange implications in terms of efficiency, and which method would work best for the feeding and consuming steps around those stations. Also taught us about reordering and parallelizing certain tasks, even if those orders and parallelizations were not optimal in their own right.

* If you know there will be a heavy bunch of orders for a certain type of item (e.g. daily special) you can start cooking batches before the orders come in, even if there are not yet orders, optimizing the cook time. Essentially just in time delivery stuff. Similar with fries (this place used a 2 stage fry cooking process).

* Exceptional orders and out of band mechanisms: instead of trying to make the main workflow handle exceptional orders (very large, weird items, etc) it is is easier to have a second workflow or an ad-hoc workflow for that situation - it prevents interruptions, starvation issues, etc for the main queue.

* It is very amusing to watch the puzzled look on customer's faces when they see the cooks white-boarding math equations during lulls :)

At busy times, the Starbucks near me even goes farther. They have an extra employee ask people in line for their drink orders and marks them on the cup before you even reach the cashier so that the only bottleneck is actually paying for the drink.

Yes, because I don't run away after I've paid. Essentially I'm blocked with a lock after I've paid which is

a.) released when I get my coffee

b.) released with a timeout (I don't want to wait any longer)

The illustration makes it easy to see how credit or gift cards benefit Starbucks' workflow, by removing the price interaction. Regulars with a card can just hand the card over with the order and payment is immediately processed. This removes the round trip around price.

Another place where 2PC isn't used is in bank accounts, even though the "bank account transfer" example is the stereotypical example introducing transactions. Networked credit banking was basically worked out in 4th century BC Egypt.

Excellent analogy.

I guess none of you has ever set foot in a coffee shop in Italy. Compared to that Starbucks is the most inefficient place ever. I'd like to have hard numbers to prove that, but the sheer fact that one espresso is about $1 in Italy, the cost off coffee is comparable and the cost of land is much higher than in the US, makes me think that Italian baristas are at least twice as efficient.