Event Buses Explained: The Message Board Your Project Has Been Missing

Here's a situation I've seen way too many times: you're building a feature where users can register for your app. Simple enough. They submit a form, you create their account in the database, done.

Then marketing asks you to send a welcome email. Okay, add that to the registration function.

Then the analytics team wants to track new signups. Add that too.

Then you need to create a default profile for them. Add it.

Then someone wants to notify the sales team for certain types of users. Add it.

Before you know it, your simple registration function has become a 200-line monster that does fifteen different things. And every time one of those things breaks or needs to change, you're touching this critical piece of code that handles user registration. One bad deploy and nobody can sign up.

Worse, each of those features is now tightly coupled to your registration logic. Want to send emails from somewhere else? Too bad, that code is buried in the registration function. Want to test registration without triggering all the side effects? Good luck.

This is the problem event buses solve. And once you understand the pattern, you'll start seeing places to use it everywhere.

The Bulletin Board Analogy

To understand Event Buses, consider an office analogy.

Option 1 (Slow): The boss tells 50 employees individually about free pizza. This is slow and requires the boss to know and track every employee.

Option 2 (Efficient): The boss posts "Free pizza in the break room!" on a bulletin board. Interested employees check the board and react. The boss (event publisher) emits a message (event) without knowing or caring who reads it. Employees (event subscribers) handle the event.

An event bus is this bulletin board for your app. This pattern solves the fundamental problem of broadcasting information to interested parties without the broadcaster needing to know the recipients.

What Is an Event Bus?

An event bus is a pattern (and often a piece of code) that lets different parts of your application communicate without being directly connected.

There are three key concepts:

Events are things that happen in your system and are facts about the past (e.g., "User registered," "order placed," "payment completed," "file uploaded"). Other parts of the system may want to know about them.

Publishers (or emitters) are the parts of your code that announce when events happen. They don't know or care who's listening.

Subscribers (or listeners) are the parts of your code that care about specific events. They register their interest upfront, get notified when events happen, and then react.

The event bus sits in the middle, connecting publishers and subscribers without them knowing about each other.

Here's what that looks like conceptually:

Publisher                Event Bus              Subscribers
   |                         |                      |
   |--- "User Registered" -->|---> Email Service ---|
   |                         |---> Analytics -------|
   |                         |---> Profile Creator -|
   |                         |---> Sales Notifier --|

The publisher just emits the event. The event bus handles distribution to all interested subscribers. Clean, decoupled, flexible.

Building a Simple Event Bus

Let's build one. The simplest version is surprisingly small:

class EventBus {
  constructor() {
    this.subscribers = {};
  }

  // Subscribe: "Call me when this event happens"
  on(eventName, callback) {
    if (!this.subscribers[eventName]) {
      this.subscribers[eventName] = [];
    }
    this.subscribers[eventName].push(callback);
  }

  // Emit: "This event just happened, notify everyone who cares"
  // Note: In production, wrap callbacks in try/catch to isolate failures
  emit(eventName, data) {
    if (!this.subscribers[eventName]) {
      return; // Nobody's listening, that's fine
    }
    
    this.subscribers[eventName].forEach(callback => {
      callback(data);
    });
  }

  // Unsubscribe: "Stop calling me about this"
  off(eventName, callback) {
    if (!this.subscribers[eventName]) {
      return;
    }
    
    this.subscribers[eventName] = this.subscribers[eventName]
      .filter(cb => cb !== callback);
  }
}

// Create a shared event bus
const eventBus = new EventBus();

That's it. That's the core pattern. Let's see it in action:

// Different parts of your app subscribe to events they care about

// Email service listens for user registration
eventBus.on('user:registered', (user) => {
  console.log(`Sending welcome email to ${user.email}`);
  // sendWelcomeEmail(user.email);
});

// Analytics service listens for the same event
eventBus.on('user:registered', (user) => {
  console.log(`Tracking signup for user ${user.id}`);
  // analytics.track('User Signed Up', user);
});

// Profile service listens too
eventBus.on('user:registered', (user) => {
  console.log(`Creating default profile for ${user.id}`);
  // createDefaultProfile(user.id);
});

// Now when user registration happens, just emit the event
function registerUser(email, password) {
  // Do the actual registration
  const user = { 
    id: generateId(), 
    email, 
    createdAt: new Date() 
  };
  
  saveToDatabase(user);
  
  // Announce what happened
  eventBus.emit('user:registered', user);
  
  // That's it! We're done. Everything else happens automatically.
  return user;
}

See how clean that is? The registration function does one thing: registers the user. It doesn't know about emails, analytics, or profiles. It just announces "user registered" and moves on.

All the other stuff happens automatically because those services are subscribed to that event. If you want to add a new feature that triggers on registration, you don't touch the registration code at all. You just add another subscriber:

// New requirement: notify sales team for enterprise signups
eventBus.on('user:registered', (user) => {
  if (user.email.endsWith('@bigcompany.com')) {
    console.log(`Notifying sales team about enterprise signup: ${user.email}`);
    // notifySalesTeam(user);
  }
});

No changes to existing code. No risk of breaking registration. Just add a listener, and you're done.

Why This Matters

Decoupling:

Features like email, analytics, and profiles are independent. The registration code doesn't need to know about its subscribers. Changes to one subscriber won't affect others or the publisher.

Flexibility:

Easily add new features (subscribers) that react to an event without changing the core event-emitting logic. Features can be temporarily disabled or conditionally run.

Testability:

Testing can be simplified by not registering side-effecting subscribers (like email or analytics) or by registering mock subscribers to verify correct calls.

Reusability:

Events can be reused across different parts of the application. The event bus handles different events ("user:registered," "user:login") using the same simple pattern.

Clarity:

The list of subscribers provides a clear, self-documenting list of "what happens when this event occurs," which is clearer than a single large function with multiple side effects.

Scaling Up (And Down)

Here's the beautiful thing about event buses: the core logic stays the same whether you're building a small app running on one server or a distributed system spanning multiple services.

In-memory (what we just built): Perfect for monolithic applications where everything runs in the same process. Fast, simple, no infrastructure needed. Events are just function calls.

HTTP-based: For distributed systems, the pattern is identical, but the implementation changes. Instead of storing callbacks in memory, subscribers register webhook URLs. When an event happens, the event bus makes HTTP requests to notify subscribers:

// Conceptually the same, different transport
class DistributedEventBus {
  constructor() {
    this.webhooks = {}; // { eventName: [url1, url2, ...] }
  }

  // Subscribe by registering a webhook URL
  on(eventName, webhookUrl) {
    if (!this.webhooks[eventName]) {
      this.webhooks[eventName] = [];
    }
    this.webhooks[eventName].push(webhookUrl);
  }

  // Emit by calling all registered webhooks
  async emit(eventName, data) {
    if (!this.webhooks[eventName]) return;
    
    const notifications = this.webhooks[eventName].map(url =>
      fetch(url, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ event: eventName, data })
      })
    );
    
    await Promise.all(notifications);
  }
}

Same on and emit pattern. Same logic. Different transport mechanism.

Message queues: For high-scale systems, you might use RabbitMQ, Kafka, or Redis Pub/Sub. The pattern remains identical; publishers emit events, subscribers register interest, but the infrastructure handles reliability, ordering, retry logic, and persistence.

The point is: learn the pattern once, apply it at any scale. A local event bus in your monolith teaches you the same concepts you'll use with Kafka in a microservices architecture.

Real-World Example: Order Processing

Let's look at a more realistic scenario. An e-commerce system processes orders:

const eventBus = new EventBus();

// Payment service
eventBus.on('order:placed', async (order) => {
  console.log(`Processing payment for order ${order.id}`);
  const paymentSuccessful = await processPayment(order);
  
  if (paymentSuccessful) {
    eventBus.emit('order:paid', order);
  } else {
    eventBus.emit('order:payment-failed', order);
  }
});

// Inventory service
eventBus.on('order:paid', (order) => {
  console.log(`Reducing inventory for order ${order.id}`);
  order.items.forEach(item => {
    reduceStock(item.productId, item.quantity);
  });
  eventBus.emit('order:inventory-updated', order);
});

// Shipping service
eventBus.on('order:inventory-updated', (order) => {
  console.log(`Creating shipping label for order ${order.id}`);
  createShippingLabel(order);
  eventBus.emit('order:ready-to-ship', order);
});

// Notification service
eventBus.on('order:ready-to-ship', (order) => {
  console.log(`Notifying customer about order ${order.id}`);
  sendEmail(order.customer.email, 'Your order is being prepared!');
});

eventBus.on('order:payment-failed', (order) => {
  console.log(`Notifying customer about payment failure for order ${order.id}`);
  sendEmail(order.customer.email, 'Payment failed, please try again');
});

// The order controller just kicks things off
function placeOrder(orderData) {
  const order = {
    id: generateId(),
    ...orderData,
    status: 'pending',
    createdAt: new Date()
  };
  
  saveOrder(order);
  eventBus.emit('order:placed', order);
  
  return { orderId: order.id, status: 'processing' };
}

Notice the chain of events: order placed → payment processed → inventory updated → shipping prepared → customer notified. But each step only knows about its immediate inputs and outputs. The payment service doesn't know about inventory. Inventory doesn't know about shipping. They're all independent, connected only through events.

If you need to add a new step, say, checking for fraud, you just add another subscriber:

eventBus.on('order:placed', async (order) => {
  const isSuspicious = await checkForFraud(order);
  if (isSuspicious) {
    eventBus.emit('order:flagged-for-review', order);
    // Payment service might listen for this and pause processing
  }
});

No changes to existing services. Just wire in the new behaviour.