Following its shambolic first few days in business, when fickle customers exposed the flaws in its order fulfillment process (as described in the “lost update” anecdote in the preceding section), Restbucks took a long, hard look at the ad hoc coordination mechanisms behind the counter and decided to implement a more robust process—one designed to guarantee that customers got what they wanted, no matter how many times they changed their minds. In the following sections, we’re going to show how Restbucks now implements order fulfillment using AtomPub.
Before we dive into the details, let’s review the steps in the fulfillment sequence:
A cashier takes an order from a customer.
The cashier adds the order to a list of orders awaiting fulfillment and takes payment from the customer.
The store’s baristas work their way through the list of unfulfilled orders, usually but not always picking up the oldest first.
When a barista finishes making all the drinks in an order, he hands them over to the customer.
Prior to the drinks being prepared, the order can be modified or canceled.
What we’re facing here, from an application integration point of view, is a case of competing consumers. In the competing consumer pattern, multiple receivers—baristas in this case—process messages (orders) from a single point-to-point channel. The success of the pattern relies on there being no temporal dependencies between messages. That is, message B can be successfully ...