DEV Community

Hrishikesh Dalal
Hrishikesh Dalal

Posted on

EP 15: Pub/Sub - Stop Chaining Your Services

#systemdesign #pubsub #beginners

You just launched your dream startup, "DevEats"—a food delivery app for developers who need serious fuel while debugging. Your signature item? The "Triple Stack Smash Burger with Truffle Fries."

In the beginning, life was simple. You had one backend service (a monolith). A user ordered a burger, your code saved it to the database, and life was good.

But you grew fast. Now, YOU are the owner of a scaling platform, and your code is turning into a tangled mess of spaghetti (pun intended).

Here is why you need the Pub/Sub pattern, explained through the lens of your own burger empire.

1. What is the Need? (The "Smash Burger Panic")

Let’s look at your current codebase. When a user clicks "Order Burger", your backend does this strictly in order:

  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 your admin dashboard sales graph.

The Problem:
One Friday night, your Email Provider goes down.
Because your code is sequential (A -> B -> C -> D), the entire process crashes at Step 3.

The payment went through (Step 1), but the kitchen printer never got the ticket (Step 4).

Now you have a hangry developer who paid for a Triple Stack Burger that isn't being made. They are angry, and your support inbox is flooding.

The Need:
You need a way for your system to say, "Hey, a burger was just ordered!" without caring who is listening or if the email service is currently online. You need to decouple the sender from the receivers.

2. The Solution: Pub/Sub Architecture

In a Publish/Subscribe (Pub/Sub) model, we split your architecture into three parts:

  1. The Publisher (You/The Order Service): You simply shout a message ("Order #505: Triple Smash Burger!") into a channel. You don't know who is listening. You don't care.
  2. The Topic (The Channel): A dedicated lane for specific types of messages (e.g., events.burger_ordered).
  3. The Subscribers (The Listeners): Independent services that have signed up to listen to that topic.

The New Flow:

  • User orders the burger.
  • You (Order Service) publish a message to the events.burger_ordered topic.
  • Done. You return "Success" to the user immediately.

Meanwhile, in the background:

  • The Kitchen Service hears the message and instantly prints the ticket on the grill station.
  • The Notification Service hears the message and tries to send an email. If it fails (because the provider is down), it retries later. Crucially, it does not stop the kitchen from cooking.
  • The Rewards Service hears the message and adds 50 points to the user's account.

3. When to Use It?

You shouldn't use Pub/Sub for everything. Use it when:

  • 1-to-Many Relationships: One event (Burger Ordered) triggers multiple, unrelated actions (Email, Kitchen Display, Inventory Check).
  • Decoupling is Vital: You want to add a new "SMS Service" next week without rewriting your existing Order Service code.
  • Asynchronous Processing: You don't want the user staring at a loading spinner while your server generates a PDF invoice.

4. The Pros and Cons

✅ The Pros

  • Scalability: You can add 50 new subscribers (e.g., a "Surge Pricing Bot") without touching the original Publisher code.
  • Reliability: If one subscriber crashes (e.g., the Email service), the others (Kitchen, Analytics) keep working perfectly. The burger still gets made.
  • Speed: The Publisher fires the event and moves on. The user gets a "Your Order is Placed!" screen instantly.

❌ The Cons

  • Complexity: You are introducing a new component (a Broker like Redis, Kafka, or Google Pub/Sub) to manage.
  • Debugging is a Nightmare: You can't just follow a linear stack trace anymore. You have to trace messages flying across a network.
  • Consistency Issues: What if the message is delivered twice? (Does the customer get charged twice? Does the chef make two burgers?). You have to write code to handle these edge cases.

5. Pub/Sub vs. Message Queue (The Confusion)

This is where most devs get tripped up. Both use "Brokers," but the intent is different.

Scenario A: Pub/Sub (The "Megaphone")

Use Case: You launch a New limited-edition Ghost Pepper Burger.
Logic: 1 Message -> Many Receivers.

  • Publisher: The Menu Manager Service.
  • Subscribers:
  • App Notification Service: Pushes "New Burger Alert!" to all users.
  • Inventory Service: Reserves spicy peppers in the warehouse.

  • Marketing Service: Posts automatically to Twitter/X.

  • Why? Everyone needs to know about this event to do their own specific job.

Scenario B: Message Queue (The "Grill Line")

Use Case: It's lunch rush. You have 500 burger orders coming in.
Logic: 1 Message -> 1 Receiver (Load Balancing).

  • Producer: The Order Service pushes 500 tickets to a Queue.
  • Consumers (Chefs): You have 5 Chefs (Chef A, B, C, D, E).
  • The Flow: Chef A grabs Ticket #1. Chef B grabs Ticket #2.
  • Why? If Chef A is grilling the burger for Ticket #1, you do not want Chef B to grill the same burger. That’s a waste of meat. You want to distribute the work, not broadcast it.

The 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)
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!

Top comments (0)