EP 15: Pub/Sub - Stop Chaining Your Services
Source: Dev.to
Pub/Sub for Your “DevEats” Burger Empire
You just launched DevEats—a food‑delivery app for developers who need serious fuel while debugging.
Your signature item? The “Triple Stack Smash Burger with Truffle Fries.”
1. What Is the Need? (The “Smash Burger Panic”)
The current (sequential) flow
| Step | Service | Action |
|---|---|---|
| 1 | Payment Service | Charge the credit card $25 |
| 2 | Order Service | Save the order to the database |
| 3 | Notification Service | Send a receipt email |
| 4 | Kitchen Service | Print the ticket for the chef |
| 5 | Analytics Service | Update the admin‑dashboard sales graph |
The problem
On a Friday night the email provider goes down. Because the code is strictly sequential (A → B → C → D), the whole process crashes at step 3.
- The payment succeeded (step 1).
- The kitchen never got the ticket (step 4).
Result: a hangry developer who paid for a Triple Stack Burger that isn’t being made.
The need
You need a way for the system to say, “Hey, a burger was just ordered!” without caring who is listening or whether the email service is currently online. In other words, you need decoupling between the sender and the receivers.
2. The Solution: Pub/Sub Architecture
In a Publish/Subscribe (Pub/Sub) model the architecture is split into three parts:
- Publisher – e.g., the Order Service. It simply publishes a message (
"Order #505: Triple Smash Burger!") to a channel. - Topic – the channel that groups a specific type of message, e.g.,
events.burger_ordered. - Subscribers – independent services that have subscribed to that topic.
New flow
- User orders the burger.
- Order Service publishes a message to
events.burger_ordered. - Order Service immediately returns “Success” to the user.
Background processing (asynchronously)
| Subscriber | Action |
|---|---|
| Kitchen Service | Prints the ticket for the chef. |
| Notification Service | Tries to send the receipt email; retries later if the provider is down. |
| Rewards Service | Adds 50 points to the user’s account. |
| (any new service) | Can be added without touching the Order Service. |
3. When to Use Pub/Sub?
| Situation | Why Pub/Sub? |
|---|---|
| 1‑to‑Many relationships | One event (burger ordered) triggers multiple unrelated actions (email, kitchen display, inventory check). |
| Decoupling is vital | Adding a new “SMS Service” later requires no changes to the existing Order Service. |
| Asynchronous processing | The user isn’t forced to wait while the server generates a PDF invoice or sends emails. |
Tip: Don’t use Pub/Sub for everything—only when you truly need broadcast‑style, loosely‑coupled communication.
4. Pros and Cons
✅ The Pros
| Benefit | Explanation |
|---|---|
| Scalability | Add 50 new subscribers (e.g., a “Surge‑Pricing Bot”) without touching the publisher. |
| Reliability | If one subscriber crashes (e.g., Email service), the others (Kitchen, Analytics) keep working. |
| Speed | Publisher fires the event and moves on; the user sees “Your Order is Placed!” instantly. |
❌ The Cons
| Drawback | Explanation |
|---|---|
| Complexity | Introduces a broker (Redis, Kafka, Google Pub/Sub, etc.) to manage. |
| Debugging | No linear stack trace; you must trace messages across the network. |
| Consistency | Duplicate delivery can happen; you must make your handlers idempotent (e.g., avoid double charges or double burgers). |
5. Pub/Sub vs. Message Queue (The Confusion)
Both patterns use a broker, but their intent differs.
Scenario A – Pub/Sub (The “Megaphone”)
| Use case | Logic | Publisher | Subscribers |
|---|---|---|---|
| Launch a new limited‑edition Ghost Pepper Burger | 1 message → many receivers | Menu Manager Service | • App Notification Service (push alert) |
| • Inventory Service (reserve peppers) | |||
| • Marketing Service (tweet) |
Why? Everyone needs to know about the event to perform their own specific job.
Scenario B – Message Queue (The “Grill Line”)
| Use case | Logic | Producer | Consumers |
|---|---|---|---|
| Lunch rush with 500 burger orders | 1 message → 1 receiver (load‑balancing) | Order Service (pushes tickets to a queue) | 5 Chefs (A‑E) each pull a ticket, ensuring no duplicate work. |
Why? You want to distribute work, not broadcast it. Each order should be processed by exactly one chef.
6. Cheat Sheet
| Feature | Pub/Sub | Message Queue |
|---|---|---|
| Philosophy | “Everyone needs to know this happened.” | “Someone please do this job.” |
| Distribution | Broadcast (one‑to‑all) | Point‑to‑point (one‑to‑one) |
| Typical Use | Event notification, fan‑out processing | Task distribution, work‑queue processing |
| Ordering Guarantees | Usually at‑least‑once; ordering per subscriber may vary | Often FIFO per queue |
| Scalability | Add subscribers freely | Add consumers to increase throughput |
| Reliability | Each subscriber handles its own retries | Broker can retry delivery until a consumer acknowledges |
Bottom line: Use Pub/Sub when you need a broadcast of an event to many independent services, and use a Message Queue when you need to distribute work items among multiple workers. Both patterns can coexist in a modern, scalable architecture—just pick the right tool for the right job.
Burger Example
“New Menu Item Launched!” – (Tell everyone)
“Grill this patty” – (One chef does it)
Final Words
As the owner of DevEats, switching to Pub/Sub saved your Friday night rush. When your Email Service crashed, nobody noticed. The orders kept flowing, the smash burgers kept sizzling, and the emails were just queued up and sent an hour later.
That is the power of decoupling. 🍔 Code responsibly!