Event Bus

3 min read

Also known as: Message Bus, Pub/Sub System, Event Stream

A messaging infrastructure that lets services publish events and subscribers consume them — decoupling producers from consumers.

Definition

An event bus is a messaging infrastructure pattern where services publish events (a thing happened) and any number of subscribers can consume those events independently. The bus sits between producers and consumers, broadcasting events without requiring either side to know about the other directly.

The defining benefit is decoupling: a service that publishes 'user.signed_up' doesn't need to know which services react to it. Marketing automation might enroll the user in onboarding emails. Analytics might log the signup. Billing might create a customer record. The publisher fires once; all consumers react independently.

Common event bus implementations include Apache Kafka, AWS EventBridge, Google Cloud Pub/Sub, Redpanda, NATS, and RabbitMQ. The choice depends on throughput needs, durability requirements, ordering guarantees, and operational complexity.

Why It Matters

Event buses are what make modular, scalable systems possible. Without one, every new consumer of an event requires modifying the producer — leading to tightly-coupled spaghetti integrations. With one, adding a new consumer is purely additive: the new service subscribes to the existing event stream without touching the producer.

The biggest mistake is treating event buses as 'just message queues.' Queues are point-to-point (one producer, one consumer per message). Event buses are publish/subscribe (one producer, many consumers per event). Using the wrong pattern leads to architectural mismatches that compound over time.

Examples in Practice

A SaaS company's AWS EventBridge bus carries events like 'user.created', 'subscription.upgraded', 'invoice.paid'. Multiple downstream services subscribe: marketing automation (for welcome flows), CRM sync (for record updates), analytics (for funnel tracking), notifications (for in-app alerts). Each subscribes independently; the producer publishes once.

An e-commerce platform uses Kafka to handle order events. A single 'order.placed' event is consumed by inventory (decrement stock), fulfillment (initiate shipping), accounting (record revenue), email (send confirmation), and recommendations (update buyer profile). Adding a new consumer doesn't require touching the order service.

A B2B SaaS company replaces a tangle of direct service-to-service API calls with an event bus. Before: 12 services made 47 direct API calls to each other. After: 12 services publish/subscribe via the event bus with 60% fewer dependencies and dramatically simpler architecture.

Frequently Asked Questions

What is an event bus?

A messaging infrastructure where services publish events and subscribers consume them independently. The bus broadcasts events without requiring producers and consumers to know about each other directly.

How is an event bus different from a message queue?

Message queues are point-to-point (one producer, one consumer per message). Event buses are publish/subscribe (one producer, many consumers per event). Use queues for work distribution; use buses for event broadcasting.

What event bus implementations are common?

Apache Kafka, AWS EventBridge, Google Cloud Pub/Sub, Redpanda, NATS, and RabbitMQ (in pub/sub mode). Managed services (EventBridge, Pub/Sub) reduce operational complexity; self-hosted (Kafka, Redpanda) offer more control.

When should I use an event bus?

When multiple services need to react to the same business events independently. When you want producers and consumers decoupled. When the system has more than a handful of services and direct point-to-point integrations would create dependency spaghetti.

What's the downside of event buses?

Added complexity (you're operating an additional infrastructure component). Eventual consistency (consumers may process events with delay). Debugging difficulty (tracing causality across pub/sub flows requires tooling like distributed tracing). Worth the trade-off at scale; overkill for small systems.

How do I name events?

Past-tense verb + noun pattern: 'user.created', 'order.placed', 'subscription.upgraded'. Avoid command-style names ('createUser', 'placeOrder') — events describe things that happened, not actions to take.

Do all consumers see all events?

Depends on the implementation. Topic-based buses (Kafka, Pub/Sub) let consumers subscribe to specific event types. Channel-based buses route events to specific channels. Most modern implementations support flexible subscription patterns where consumers see only the events they care about.

What happens if a consumer fails to process an event?

Depends on the bus's delivery guarantees. At-least-once delivery (most common) retries failed processing. At-most-once delivery accepts that some events may be lost on failure. Exactly-once delivery is harder to achieve but possible in some systems. Choose guarantees that match your use case's tolerance.

The AMW Suite