Pub/Sub System

Phase 1: Requirements & Use Cases

Interviewer: "Design a pub/sub messaging system."

Candidate: "Let me confirm scope. We're building an in-process publish-subscribe system — a message bus where publishers emit events to named topics, and multiple subscribers receive each event independently. This is NOT a distributed message broker like Kafka or RabbitMQ; we're designing the OOD model within a single process. Does that match?"

Interviewer: "Yes. What actors and use cases are you targeting?"

Candidate: "The actors are Publishers (emit events), Subscribers (receive events), and an Event Bus / Broker (routes messages). The core use cases are:

1. subscribe(topic, handler) — a subscriber registers interest in a topic with a callback
2. unsubscribe(topic, subscriber) — remove a subscriber from a topic
3. publish(topic, event) — a publisher broadcasts an event to all subscribers of a topic
4. create_topic(name) — register a new topic
5. list_topics() — enumerate available topics
6. Async delivery — published events are delivered asynchronously so the publisher doesn't block on slow subscribers"

Interviewer: "What about guaranteed delivery? What happens if a subscriber is slow or throws an exception?"

Candidate: "I'll design for best-effort delivery in V1 — if a subscriber's handler throws, we log and continue to the next subscriber. The publisher always returns after submitting the event to the bus; delivery happens on a thread pool. I'll note where durable delivery (acking, dead-letter queues) would plug in as a V2 extension."

WHY: Guaranteed delivery requires persisting events and tracking per-subscriber acknowledgements — that's a significant scope increase. Best-effort covers the dominant…