Queues Between Services

So far, the order queue sits inside the commerce service: one part accepts orders, and another part places them. A queue can also sit between two services.

After the order worker places order 93, the shopper gets a confirmation email. The notification service sends it.

Calling the notification service

Suppose the order worker calls the notification service with RPC to send the email, and waits for the call to return. During the sale, the notification service may be slow, or it may be down.

If it is slow, the order worker waits for each call. Every order takes longer to place, and the orders behind it wait longer in the order queue.

If it is down, the call fails. Order 93 is already placed, so we cannot fail the order. Either the email is lost, or the order worker keeps trying while the orders behind it wait.

An email queue

Instead, the order worker sends a message to an email queue and moves on to the next order. Here is the message for order 93:

{
  "shopId": "mugshop",
  "orderId": "93",
  "email": "order-placed"
}

The order worker is the producer for the email queue, and the notification service is its consumer. The message carries no email address. Recall that the five services share one database, so the notification service reads the shopper’s email address from there.

If the notification service is slow, the messages wait in the email queue, and the order worker does not wait for them. If the notification service is down, the messages wait in the email queue until it is back, and then it sends the emails.

One broker for both queues

The email queue does not need a broker of its own. The broker that keeps the order queue keeps the email queue too:

graph TD
    H[Commerce service: handles requests] --> OQ
    subgraph B[Broker]
        OQ[Order queue]
        EQ[Email queue]
    end
    OQ --> W[Commerce service: order worker]
    W --> EQ
    EQ --> N[Notification service]

The order worker is the consumer of the order queue and the producer for the email queue.

When to use a queue

Use a queue when the caller does not need the result in its response, and the work:

• comes in bursts larger than the system can handle at once,
• takes too long to do inside a request, or
• goes to a service that may be slow or down.

The flash sale is an example of the first case, and the email is an example of the third. The cost is that the result arrives later, so the client must find out about it some other way. The storefront, for example, polls for the order.