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

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.

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.

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.

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.

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.

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."

Well for drive through Starbucks you order first and pay second, so just envision that scenario.

Still no Erlang comments?