Designing a Concurrent Event Bus

In this lesson, you will learn how to build a scalable, decoupled communication backbone using a concurrent event bus.

The Architecture of Decoupling

An event bus acts as the central nervous system of a complex system. Instead of components calling each other directly (which creates tight coupling), a component simply "publishes" an event to the bus, and any number of "subscribers" react to it. In Rust, achieving this with high concurrency requires balancing thread safety, memory ownership, and efficient dispatch.

Handling Multi-Subscriber Dispatch

To build this, we use a central Registry that maps EventType to a list of channel senders. When an event is published, the bus iterates through these senders to broadcast the data. Because we want to avoid blocking the publisher while waiting for a slow subscriber, we leverage tokio::sync::mpsc or similar channels to provide asynchronous buffering.

use std::sync::Arc;
use tokio::sync::broadcast;

pub struct EventBus<T: Clone + Send + 'static> {
    // We use a broadcast channel for N-way fan-out
    sender: broadcast::Sender<T>,
}

impl<T: Clone + Send + 'static> EventBus<T> {
    pub fn new(capacity: usize) -> Self {
        let (sender, _) = broadcast::channel(capacity);
        Self { sender }
    }

    pub fn subscribe(&self) -> broadcast::Receiver<T> {
        self.sender.subscribe()
    }

    pub fn publish(&self, event: T) {
        let _ = self.sender.send(event);
    }
}

Avoiding Contention

The implementation above uses a broadcast channel, which is highly efficient for many-to-many communication. However, as you scale to millions of tasks, a single bus can become a bottleneck. To keep the hot path clear, we decouple the bus from the processing logic. By moving the event handling into dedicated task pools, we ensure that an expensive operation in one component doesn't stall the event distribution mechanism.

When designing this, always consider the "Backpressure" problem: what happens if subscribers cannot keep up with the publisher? Using bounded channels ensures you maintain system stability under load, preventing memory exhaustion (OOM) by forcing the publisher to wait or drop events when the bus is saturated.

Key Takeaway: A robust concurrent event bus decouples producers from consumers using asynchronous channels, enabling independent scaling while preventing system-wide bottlenecks through bounded buffering.