5 ms·

Starbucks Does Not Use Two-Phase Commit

34 points by Bluem00 19y ago

meat-eater 19y ago
In the starbucks shops from where I live, you have to pay when you order. That is before they write your name in your cup. So the problem the article is talking about simply does not apply.
- caudicus 19y ago
  Well for drive through Starbucks you order first and pay second, so just envision that scenario.
- joshwa 19y ago
  Starbucks in NYC will radio or call out your drink order to the barista while you're waiting in line for the cashier, then correlate by drink type (barista yells "iced tall 2-pump classic iced coffee!") side note-- there is a specific order to the way they call the drinks, too, as in the example above: iced (go to the stack of plastic cups) tall (pick the size) 2-pump classic (put the flavor/sugar syrup in the cup) iced coffee (finally put the beverage in). Helps the baristas remember your drink order by correlating the auditory with the physical, aiding short-term memory.
- neilc 19y ago
  On the contrary, that is precisely the scenario the author is describing: "The interaction between two parties (customer and coffee shop) consists of a short synchronous interaction (ordering and paying) and a longer, asynchronous interaction (making and receiving the drink). This type of conversation is quite common in purchasing scenarios."
bprater 19y ago
Using Starbucks as an example of async communications is brilliant! I can explain async to everyone I know now. Great article.
- davidcthompson 19y ago
  And the idea that not all transactions have to work perfectly for a business to run. Every Starbucks leaves a few unclaimed drinks ever day, but they are still raking in the cash.
  - bsaunder 19y ago
    I think many enterprise managers have a philosophically hard time with this notion. And for some business models, perhaps they are correct to be concerned. In general, I think async with error correction mechanisms is the way to go.
michaelneale 19y ago
Gregor is a good writer - he makes it very clear. His stuff kind of got lost in the web 2.0 noise about how you don't need enterprisey stuff like integration or messaging, but his points are always valid. Good to see people are still reading him.
keating 19y ago
Still no Erlang comments?

34 points by Bluem00 19y ago

In the starbucks shops from where I live, you have to pay when you order. That is before they write your name in your cup. So the problem the article is talking about simply does not apply.

caudicus 19y ago
Well for drive through Starbucks you order first and pay second, so just envision that scenario.
joshwa 19y ago
Starbucks in NYC will radio or call out your drink order to the barista while you're waiting in line for the cashier, then correlate by drink type (barista yells "iced tall 2-pump classic iced coffee!") side note-- there is a specific order to the way they call the drinks, too, as in the example above: iced (go to the stack of plastic cups) tall (pick the size) 2-pump classic (put the flavor/sugar syrup in the cup) iced coffee (finally put the beverage in). Helps the baristas remember your drink order by correlating the auditory with the physical, aiding short-term memory.
neilc 19y ago
On the contrary, that is precisely the scenario the author is describing: "The interaction between two parties (customer and coffee shop) consists of a short synchronous interaction (ordering and paying) and a longer, asynchronous interaction (making and receiving the drink). This type of conversation is quite common in purchasing scenarios."

bprater 19y ago

Using Starbucks as an example of async communications is brilliant! I can explain async to everyone I know now. Great article.

davidcthompson 19y ago
And the idea that not all transactions have to work perfectly for a business to run. Every Starbucks leaves a few unclaimed drinks ever day, but they are still raking in the cash.
- bsaunder 19y ago
  I think many enterprise managers have a philosophically hard time with this notion. And for some business models, perhaps they are correct to be concerned. In general, I think async with error correction mechanisms is the way to go.

michaelneale 19y ago

Gregor is a good writer - he makes it very clear. His stuff kind of got lost in the web 2.0 noise about how you don't need enterprisey stuff like integration or messaging, but his points are always valid. Good to see people are still reading him.

keating 19y ago

Still no Erlang comments?