Card 05/ 09
Pub/Sub Example: One Order Event, Three Services
Billing, email and analytics each react, and the order service waits for none of them.
Publish/subscribe lets one event reach several services that each do something different with it. This example follows an order placed on a shop: one event, three services reacting to it, and then a fourth service added without changing the order service at all.
What happens. The order service saves the order, publishes order-placed with the order's id, items and total, and replies to the customer. The topic copies the event into three queues. Billing raises the invoice, email sends the receipt, and analytics counts the sale, each at its own pace.
When one fails. The email service is down for ten minutes. Its queue fills with receipts while billing and analytics carry on unaffected. When email recovers, it works through its queue, and the receipts go out late but complete.
Adding a fourth. The warehouse wants to start packing as soon as an order is placed. It creates its own queue, subscribes it to order-placed, and from then on receives every order.
Nobody touched or redeployed the order service. It does not know the warehouse exists.
How it relates to the concept. Every subscriber received every event, the publisher knew none of them, and a queue in front of each subscriber kept its copy safe while it was down.
So publish an event once when several services care that it happened, and let new services subscribe without asking the publisher.
← → move through sections and cards