Sure, but that’s a very quick dismissal of an analogy I can see being useful to some folks.
E-mail (a very old distributed system, heh) also follows the broad plan of “drop a message in a queue, optimistically tell the user they can get on with their life, then do various things on error” (like retry or notify the user). AWS’s queue service will deliver a message twice if the queue consumer suddenly falls over in the middle of handling an item, so it can be good if your queue consumer does something idempotent and/or cheap and mostly harmless to do twice.
Payment is full of optimism followed by corrective actions (service provider gives me service, tries to charge or invoice me, then can do a whole set of things if they can’t initially collect–or they charge me for service, fail to provide it for whatever reason, and give me a refund), though as you allude to I can’t think of an obvious case where I see those corrective actions used to deal with a pure software problem with no human/social aspect.
“You don’t always have to use transactions” is much less radical of a position today than it was in 2004, probably. I still get the sense that sometimes safety is seen as a single-dimensional thing, with one end having ACID transactions and the other sending off important work to be done async or lacking immediate consistency. I think it’s worthwhile to be reminded there’s a big design space with a lot of options.
I was a Starbucks employee at the time this was published, that’s why I remember it. Just because people are serving coffee doesn’t mean they’re stupid! My coworkers would not have had the CS background but I’m sure would have been interested to hear it; I talked with them a fair bit about astronomy.
Haha, I meant it’s helpful to folks like me! It’s easier for me to dig into an essay like “think about when you place an order at a coffeeshop…” (a concrete situation) than “compensating actions are one way to manage exceptions…” (a general class of problem). Maybe the metaphor doesn’t help you; that’s OK too!
But I also sure can’t argue with Irene’s point! One underestimates the wily barista (or non-programmer in general) at one’s peril!
I find it a little surprising that you’d make such a sweeping indictment without providing anything to substantiate your opinion. The article seems like a reasonable 1 minute overview of some interesting ideas. Is there something egregiously incorrect that I’m not seeing?
Starbucks doesn’t use anything in EIP either. The model depends on providing a token and maybe sometimes it’s there in your pickup and maybe not. The person who took your order is always there to confirm or deny (if they can remember). And there is always a one-on-one negotiation that goes on in a Starbucks line. In other words: you don’t want your system to be designed anything like Starbucks.
The main problem with EIP is that your queue has to be magical. It is always up and never looses a message. This is not realistic in any production setting I’ve been involved in. Sometimes you really do need synchronous communication, in which case the MQ is hurting you due to complexity.
And my initial response ia due to the strong emotional reaction I have due to dealing with a system and colleagues who treat the book like gospel despite the real life experience being a fragile syatem.
Without trying to claim that I’m somehow better and in a position to judge (I got criticized for that recently), I want to thank both of you for dealing with an emotional topic in a way that got calmer on iteration rather than escalating. Anger is going to happen; what we do after makes a big difference. The ability of users here to handle it is a big reason that I keep coming to the site.
Was the author making an analogy that two-phase commit is too expensive and Starbucks maximizes throughput at the risk of dropping an order or a charging a customer?
Haha, wow. I remember thinking this was interesting at the time.
It still sort-of is, from the perspective of thinking about why people aren’t computers. :)
Moral of the story seems to really be that people are not computers.
Sure, but that’s a very quick dismissal of an analogy I can see being useful to some folks.
E-mail (a very old distributed system, heh) also follows the broad plan of “drop a message in a queue, optimistically tell the user they can get on with their life, then do various things on error” (like retry or notify the user). AWS’s queue service will deliver a message twice if the queue consumer suddenly falls over in the middle of handling an item, so it can be good if your queue consumer does something idempotent and/or cheap and mostly harmless to do twice.
Payment is full of optimism followed by corrective actions (service provider gives me service, tries to charge or invoice me, then can do a whole set of things if they can’t initially collect–or they charge me for service, fail to provide it for whatever reason, and give me a refund), though as you allude to I can’t think of an obvious case where I see those corrective actions used to deal with a pure software problem with no human/social aspect.
“You don’t always have to use transactions” is much less radical of a position today than it was in 2004, probably. I still get the sense that sometimes safety is seen as a single-dimensional thing, with one end having ACID transactions and the other sending off important work to be done async or lacking immediate consistency. I think it’s worthwhile to be reminded there’s a big design space with a lot of options.
[Comment removed by author]
I was a Starbucks employee at the time this was published, that’s why I remember it. Just because people are serving coffee doesn’t mean they’re stupid! My coworkers would not have had the CS background but I’m sure would have been interested to hear it; I talked with them a fair bit about astronomy.
Haha, I meant it’s helpful to folks like me! It’s easier for me to dig into an essay like “think about when you place an order at a coffeeshop…” (a concrete situation) than “compensating actions are one way to manage exceptions…” (a general class of problem). Maybe the metaphor doesn’t help you; that’s OK too!
But I also sure can’t argue with Irene’s point! One underestimates the wily barista (or non-programmer in general) at one’s peril!
Reminds me of this classic: http://www.infoq.com/articles/webber-rest-workflow/
[Comment removed by author]
I find it a little surprising that you’d make such a sweeping indictment without providing anything to substantiate your opinion. The article seems like a reasonable 1 minute overview of some interesting ideas. Is there something egregiously incorrect that I’m not seeing?
Starbucks doesn’t use anything in EIP either. The model depends on providing a token and maybe sometimes it’s there in your pickup and maybe not. The person who took your order is always there to confirm or deny (if they can remember). And there is always a one-on-one negotiation that goes on in a Starbucks line. In other words: you don’t want your system to be designed anything like Starbucks.
The main problem with EIP is that your queue has to be magical. It is always up and never looses a message. This is not realistic in any production setting I’ve been involved in. Sometimes you really do need synchronous communication, in which case the MQ is hurting you due to complexity.
And my initial response ia due to the strong emotional reaction I have due to dealing with a system and colleagues who treat the book like gospel despite the real life experience being a fragile syatem.
Thanks for the detailed response!
Without trying to claim that I’m somehow better and in a position to judge (I got criticized for that recently), I want to thank both of you for dealing with an emotional topic in a way that got calmer on iteration rather than escalating. Anger is going to happen; what we do after makes a big difference. The ability of users here to handle it is a big reason that I keep coming to the site.
In addressing the article, maybe you should use the Principle of Charity ?
Was the author making an analogy that two-phase commit is too expensive and Starbucks maximizes throughput at the risk of dropping an order or a charging a customer?