Pub/Sub: The Invisible Glue That Makes Modern Apps Work

Publish-Subscribe is a messaging pattern where:

1. Publishers send messages without knowing who receives them.
2. Subscribers listen without knowing the sender.

This simple but powerful decoupling is why systems like

1. YouTube’s notifications
2. Uber’s ride dispatches
3. Node.js's EventEmitter (and frontend tools like Redux/Vue events)

...all handle complexity effortlessly.

Why It Matters Today?

In modern applications, Pub/Sub solves critical challenges:

1️⃣ Scalability

Need to add a new order processing step? Just subscribe!

eventBus.subscribe('order_created', applyLoyaltyPoints);

2️⃣ Maintainability

Publishers and subscribers can be developed/tested in isolation

No more "dependency spaghetti" where changing one service breaks three others

3️⃣ Performance

Async by design: Slow subscribers don't block publishers

Built for distributed systems (Redis/Kafka use this pattern at massive scale)

Example of E-commerce:

❌ Old way: Tight coupling

function processOrder() {
 chargeCard();     // Payment
 updateInventory();   // Warehouse  
 sendConfirmation();  // Email
 // Adding analytics? Must modify this function!
}

✅ Pub/Sub way

function processOrder() {
 eventBus.publish('order_processed', orderData); // That's it!
}

Services subscribe independently

paymentService.subscribe('order_processed', chargeCard);

warehouseService.subscribe('order_processed', updateInventory);

// Add analytics later without touching processOrder()

Here's why it's so powerful:

1. Loose Coupling

1. Publishers emit events without knowing who's listening.
2. Subscribers listen for events they care about.
3. No direct dependencies between modules → easier maintenance, testing, and dynamic runtime behavior.

2. Asynchronous & Ordered Handling

Emit an event once, and multiple listeners can process it independently.

Example: When a network request completes:

• Log the result
• Update UI
• Cache the data
• Notify analytics

3. Cleanup-Friendly

Unsubscribe when done (e.g., when a React component unmounts) to avoid memory leaks or duplicate handlers.

Real-World Examples

Up Next: We'll break down real implementations in Node.js, browsers, and cloud architectures.

Browser DOM

button.addEventListener('click', onClick)    // subscribe
button.removeEventListener('click', onClick)   // unsubscribe

Node.js Streams & Sockets

server.on('connection', socket => { … })     // each new client
socket.emit('data', chunk)            // push data to listeners

In-App Messaging

// analytics.js
emitter.subscribe('purchase', data => sendToAnalytics(data));

// cart.js
emitter.emit('purchase', { itemId: 123, price: 29.99 });

The Magazine Analogy

• Publisher = Magazine company (EventEmitter)
• Subscribers = Readers (callback functions)
• Event Name = Magazine title (e.g., "Tech Monthly")
• Emitting = Sending a new issue
• Unsubscribing = Canceling your subscription

How It Works:

1. You subscribe to "Tech Monthly" → emitter.subscribe('Tech Monthly', callback)
2. Publisher keeps a list of subscribers.
3. When a new issue is ready → emitter.emit('Tech Monthly', data) → all subscribers receive it.
4. Cancel anytime → unsubscribe().

Domain-Level Pub/Sub in Your App

Imagine an e-commerce app where an order triggers:

1. Confirmation email
2. Inventory update
3. Analytics recording
4. Shipping notification

1. Without Pub/Sub (Tightly Coupled)

orderService.js

import { sendConfirmationEmail } from './email';
import { updateInventory } from './inventory';
import { recordAnalytics } from './analytics';
import { notifyShipping } from './shipping';

function placeOrder(orderData) {
 // Core order logic
 const order = createOrderInDatabase(orderData);

Directly call dependent services → brittle and hard to maintain

sendConfirmationEmail(order);     // Email dependency
updateInventory(order.items);     // Inventory dependency
recordAnalytics('purchase', order);  // Analytics dependency notifyShipping(order);        // Shipping dependency

return order;
}

Problems:

1. Tangled imports: orderService.js must know about every dependency.
2. Hard to test: Mocking all dependencies in unit tests is messy.
3. Rigid structure: Adding/removing steps (e.g., a new "loyalty points" feature) requires modifying placeOrder().

If your placeOrder() function directly called each of those modules, you’d end up with tangled imports and hard-to-test code.

Instead you can:

1. Emit a single orderPlaced event with the order data.
2. Have separate modules subscribe to "orderPlaced" and do their own thing.

2. With Pub/Sub (Decoupled)

orderService.js (Publisher)

import emitter from './eventEmitter';

function placeOrder(orderData) {
 const order = createOrderInDatabase(orderData);
 emitter.emit('orderPlaced', order); // Just emit an event
 return order;
}

----------------------------

Listeners (Subscribers)

----------------------------

email.js

emitter.subscribe('orderPlaced', (order) => {
 sendConfirmationEmail(order);
});

inventory.js

emitter.subscribe('orderPlaced', (order) => {
 updateInventory(order.items);
});

analytics.js

emitter.subscribe('orderPlaced', (order) => {
 recordAnalytics('purchase', order);
});

shipping.js (Added later without touching orderService.js)

emitter.subscribe('orderPlaced', (order) => {
 notifyShipping(order);
});

Each module only worries about its own job and you can add or remove listeners without touching orderService.js.

Advantages:

1. No direct imports: orderService.js doesn’t know who handles orders.
2. Easy testing: Test each listener in isolation.
3. Flexible: Add/remove features without modifying placeOrder().

Refactoring Tip: If you see a function calling multiple unrelated services, it’s a prime candidate for pub/sub!

What Are Unrelated Services?

Unrelated services are modules or functions that:

1. Don’t logically belong together (e.g., sending emails vs. updating inventory).
2. Don’t depend on each other (one can work without the other).
3. Change for different reasons (e.g., analytics might update frequently, while shipping logic stays stable).

Rule of Thumb

If a function calls multiple things that don’t inherently depend on each other, it’s time for pub/sub!

Before:

function doSomething() {
 taskA(); // Unrelated to B/C
 taskB(); // Unrelated to A/C
 taskC(); // Unrelated to A/B
}

After:

function doSomething() {
 emitter.emit('somethingDone', data);
}

// Elsewhere:
emitter.subscribe('somethingDone', taskA);
emitter.subscribe('somethingDone', taskB);
emitter.subscribe('somethingDone', taskC);

This keeps your code flexible, testable, and maintainable.