Sometimes a picture saves you 500 words of explanation. This post is the visual companion to the event bus / pub-sub concept β four diagrams, each unpacked so you can actually see how publishers and subscribers behave before you touch a single line of code.
If you already read the full write-up on event buses, think of this as the cheat-sheet version. If you haven't, this still stands on its own.
1. Direct calls vs. event bus
On the left is the classic mistake: OrderService reaches out and calls Email, Inventory, Payment, and Shipping directly. It has to know all four addresses, handle all four failure modes, and if one of them is slow, the whole checkout slows down with it.
On the right, OrderService does one thing: it publishes order.created to the event bus and moves on. It never finds out who picked it up, how many services are listening, or whether a new one gets added next sprint.
π‘ Takeaway: the arrow count doesn't change β what changes is who owns the connection. With direct calls, the publisher owns every relationship. With a bus, the bus owns them, and the publisher owns none.
2. What's actually happening inside the bus
This is the part people skip past too quickly. The "bus" isn't one big pipe β it's a broker holding named topics (order.created, order.cancelled, payment.failed), and each topic can have multiple independent subscribers.
Notice Email Service, Analytics Svc, and Inventory Svc are all subscribed to the same topic here. Each one gets its own copy of the event. If Analytics Svc is slow to process it, Email Service doesn't wait around β they're not in a line, they're in parallel lanes.
π‘ Takeaway: subscribing is a one-time registration. After that, delivery is automatic β the broker does the fan-out, not the publisher.
3. A real checkout, end to end
This is where the theory turns into an actual business flow. Read it top to bottom:
-
Checkout Servicepublishesorder.placedβ its job ends here. -
Payment Servicepicks it up, charges the card, and publishespayment.confirmed. -
Inventory Servicereacts to that, reserves stock, and publishesstock.reserved. -
Notification Servicereacts to that and emails the customer.
Every step is a reaction to an event, never a direct request. If Notification Service is temporarily down, steps 1β6 still complete without a hiccup β the email just goes out a little later once it's back.
β οΈ Common mistake: assuming this chain always completes in order and instantly. It's asynchronous β build your system (and your customer-facing UI) to tolerate a short delay between "payment confirmed" and "email sent."
4. The cover β zoomed out
Zoom back out and this is the whole pattern in one picture: multiple publishers (Orders, Payments, Inventory) on the left, a single event bus in the middle, and multiple subscribers (Email, Analytics, Shipping, Fraud Check) on the right. Nobody on the left knows or cares who's on the right β that's the entire point of the architecture.
Quick recap
| Diagram | What it shows |
|---|---|
| 1 | Why direct service-to-service calls create fragile, tightly coupled systems |
| 2 | How topics and multiple subscribers work inside the broker |
| 3 | A real, asynchronous e-commerce checkout flow, step by step |
| 4 | The full pattern zoomed out β many publishers, one bus, many subscribers |
Next time you're sketching a system design on a whiteboard, try drawing it this way first. If you find yourself drawing arrows from one service to five others, that's usually the signal to introduce a bus.
Got a diagram of your own event-driven system? Drop it in the comments β always curious to see how different teams structure their topics.
Top comments (0)