What the Shopper Sees

When the shopper places order 93, the storefront gets this response to placeOrder:

{
  "data": {
    "placeOrder": { "id": "93", "status": "PROCESSING" }
  }
}

The storefront shows the shopper that the order is processing. The order is placed later, when the consumer takes it from the queue. So how does the storefront learn when the order is placed?

Polling for the order

We saw polling in the chapter on real-time chat: the client sends the same request every few seconds and checks whether anything changed. Here, the storefront sends this query every two seconds:

query {
  order(id: "93") {
    id
    status
  }
}

Until the order is placed, the saved order 93 has the status PROCESSING, so the storefront keeps showing “processing”. When the consumer finishes with the order, its status becomes PLACED or FAILED. It becomes FAILED if the mug sold out or the payment was declined. The next poll shows the result, and the storefront stops polling.

The status is saved in the database, so the shopper sees the same result after refreshing the page or opening the order on another device.

What polling costs

Suppose all 12,000 shoppers from the first minute are waiting and their storefronts poll every two seconds. That is $12,000/2=6,000$ reads a second. This is the most it can be, because a storefront stops polling once its order is placed or failed. Each read finds one order by its ID through an index. It does not touch the mug’s stock, so it does not slow the 100 orders a second. Polling less often would cut the requests.

With long polling, the server holds the request until it has something to send. With server-sent events, the server keeps the response open and sends each event over it. Both would tell the shopper the result as soon as the order is placed, and both avoid the repeated requests that polling sends. For order 93, I still use polling.

Polling adds at most two seconds to an order that can wait up to a minute. Long polling and server-sent events each hold a connection open for every waiting shopper, up to 12,000 at once. Throttling has the same cost: each held request keeps a connection open. Long polling and server-sent events also need the commerce service to learn as soon as the consumer changes order 93. The commerce service then sends the result over the open connection. That needs a way for one program to notify another. This chapter does not cover it. With polling, the status is already in the database, and the storefront reads it there.