Event bus
Low-level design of a publish-subscribe event bus -- topic registration, subscriber management, synchronous vs asynchronous dispatch, wildcard routing, dead-letter handling, and thread safety.
The Problem
Your microservices team has 12 services that all need to react when an order is placed. The checkout service imports every downstream service and calls them one by one: inventory, billing, notifications, analytics, fraud detection. Every time someone adds a new listener, the checkout service gets another dependency, another failure path, and another deploy. A single slow subscriber blocks the entire checkout flow.
An in-process event bus decouples publishers from subscribers. The publisher fires an event into the bus and walks away. The bus routes the event to every registered subscriber without the publisher knowing (or caring) who those subscribers are. Subscribers register themselves, the bus handles dispatch, and failed deliveries land in a dead-letter queue instead of crashing the publisher.
Design the core classes for an event bus that supports topic-based publish/subscribe, wildcard topic matching, synchronous and asynchronous dispatch modes, subscriber error isolation, dead-letter handling, and thread-safe registration.
Requirements
Clarifying Questions
Before jumping into class design, ask questions to turn the vague prompt into a concrete specification. Cover four areas: core actions, error handling, boundaries, and future extensions.
You: "Are events dispatched synchronously on the publisher's thread, or asynchronously via a thread pool?"
Interviewer: "Support both. The default is synchronous, but subscribers should be able to opt into async delivery. Some events need ordering guarantees, so we need an ordered-async mode too."
Three dispatch modes: sync (same thread), async (thread pool, no ordering), and ordered-async (single-threaded executor per topic). That means dispatch strategy is a first-class design concern.
You: "Do we support wildcard subscriptions? For example, subscribing to order.* and receiving both order.created and order.cancelled?"
Interviewer: "Yes. Support single-level wildcards with * so that order.* matches order.created but not order.payment.failed."
Wildcard matching at subscribe time. We need a matching algorithm that splits topics by . and compares segments. This is similar to MQTT topic filters.
You: "What happens when a subscriber throws an exception during event handling?"
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with NotesFromSDE Premium.