Where the Broker Runs

So far, we have followed one instance of the commerce service. In practice, the commerce service runs as several instances behind a load balancer, and each instance is a copy of the others. We can run the broker in one of two ways:

  1. A queue per instance: each instance runs its own broker, with its own order queue.
  2. One shared queue: the broker runs on its own server, and every instance uses it over the network.

A queue per instance

With a queue per instance, there is nothing extra to run. The broker is one more program on each instance’s server.

But if an instance’s server is lost, the orders waiting in its queue are lost with it. Each of those shoppers was told “processing”, and the order is never placed. Also, during the sale, the broker and the instance run on the same server, so they compete for the same CPU and memory.

One shared queue

With one shared queue, the orders are not stored on the instances. An instance can crash, or be removed after the sale, without losing any orders.

This option has two costs. There is one more server to run. And if that server is lost, every waiting order from every instance is lost.

We choose one shared queue, and we accept that there is one more server to run. But we have to do something about the second cost, losing every waiting order.

What we require of the broker

Recall that the producer waits until the broker has the message before it responds to the storefront. We require the broker to do two things before it tells the producer that it has the message:

  • Save the message to disk, so the message survives a restart of the broker.
  • Copy the message to a second server, so the message survives losing a server.

RabbitMQ is an open-source broker that we run on our own servers. We have to set it up to meet both requirements. RabbitMQ can keep a queue and its messages in memory without saving them to disk. So we mark the queue and its messages as durable. RabbitMQ then saves them to disk. We also use a quorum queue: RabbitMQ copies each message to other servers and confirms it only after most of them have it. The producer learns that a message was saved only if it turns on publisher confirms, so we turn them on too.

Amazon SQS is a broker that AWS runs for us. It stores each message on several servers before it responds to the producer. We do not have to set anything up to meet either requirement.