Pub/sub
Also called: publish/subscribe, topic, event bus.
A publisher sends an event to a topic without knowing who listens, and every subscriber to that topic gets its own copy. You can add a new consumer without changing the publisher.
Checkout sends each event once, to a topic, and doesn't know who listens. Every subscriber gets its own copy in its own queue, so one that is down only falls behind.
Events published: 0 · Copies delivered: 0
3 services subscribe to order.placed. Nothing published yet.
Say it in a prompt
When an order is placed, publish an order.placed event with {orderId, userId, total} to a topic. Subscribe three services: email sends the receipt, inventory reserves stock, analytics records the sale. Each subscriber gets its own queue and retries on its own, and ignores an orderId it has already handled. Vague vs precise prompt
Vague prompt
after an order, send an email and update the stock and analytics Typical resultCalls the three services one after another inside the checkout request. If analytics is down, checkout fails.
Precise prompt
Publish order.placed {orderId, userId, total} to a topic. Subscribe email, inventory and analytics, each with its own queue and retries, each ignoring orderIds it has seen. Checkout only waits for the publish. Typical resultCheckout returns as soon as the event is published, and a slow or broken analytics service falls behind on its own without blocking orders or emails.
Seen on
- Google Cloud Pub/Sub: Publishers send events to a topic without regard to how they will be processed, and Pub/Sub delivers them to all the services that subscribe.
- Redis: PUBLISH pushes a message to every client subscribed to a channel; delivery is at-most-once, so a subscriber that is disconnected misses it.
You might describe it as
- tell every service when something happens
- announce an event and whoever cares listens
- add a new listener without touching the sender