Following an Order Through the System

With a topic, the order worker names only the topic. It does not name the services that act on a placed order. That is what let us add the analytics service without changing the order worker. It also makes it harder to find everything that happens after an order is placed.

Where to look

Suppose a new engineer joins Shopend and wants to know everything that happens after an order is placed.

With one queue for each service, the order worker’s code lists every queue it puts a message on. Reading that code shows every service that acts on a placed order.

With a topic, the order worker’s code shows only that it publishes to order-placed. To find the services that act on it, the engineer looks in the broker for the queues on the topic’s list, and then reads the code of each subscriber.

A chain of topics

A subscriber can also publish to a topic of its own. The shipping service subscribes to order-placed and publishes to order-shipped. The order-shipped topic has subscribers of its own. To follow an order from start to end, the engineer goes back to the broker at each step.

Shopend has two topics and a handful of subscribers, so this does not take long. It takes longer as the number of topics and subscribers grows. Large systems keep a list of every topic with its publishers and subscribers, and they use tools that follow one request across services. Those tools are covered later in the course.

When to use publish/subscribe

Use publish/subscribe when more than one service acts on the same message, or when services that act on it may be added later without changing the sender.