PubSub System Design

Problem Statement

Design a publish-subscribe messaging system where publishers send messages to topics and subscribers receive messages from topics they're subscribed to. The system should decouple message producers from consumers, support multiple topics, and guarantee message delivery. Think of a simplified version of Apache Kafka or RabbitMQ.

Interviewer's framing: "Design a message broker that supports publish-subscribe semantics. Publishers push messages to named topics, and subscribers receive messages from topics they've registered interest in."

---

Requirements

Functional Requirements

Non-Functional Requirements

---

Constraints & Assumptions

• Single-node system for LLD (distributed concerns mentioned for extensibility)
• Messages are serialized byte arrays (content-agnostic)
• Maximum message size: 1MB
• Topic retention: configurable (time-based or size-based)
• Subscribers can be online or offline (messages buffered)
• Thread-safe operations required (multiple publishers/subscribers concurrently)

---

Key Entities & Relationships

Relationships

Publisher ──publishes──> Topic
Topic ──delivers──> Subscription ──routes──> Subscriber
Subscription ──uses──> Filter (optional)
Subscriber ──belongs to──> SubscriberGroup (optional)
Topic ──overflow──> DeadLetterQueue
MessageBroker ──manages──> Topic (1:N)
Topic ──contains──> Message (1:N, ordered)

---

ASCII Class Diagram

+--------------------------------------------------+
|                 MessageBroker                      |
+--------------------------------------------------+
| - topics: Map<String, Topic>                      |
| - subscriberGroups: Map<String, SubscriberGroup>  |
+--------------------------------------------------+
| + createTopic(name): Topic                        |
| + deleteTopic(name): void                         |
| + publish(topicName, message): void               |
| + subscribe(subscriberId, topicName, filter): void|
| + unsubscribe(subscriberId, topicName): void      |
| + poll(subscriberId, topicName): Message          |
| + acknowledge(subscriberId, messageId): void      |
+--------------------------------------------------+
            |                          |
            | manages                  | manages
            v                          v
+-------------------------+   +------------------------+
|         Topic           |   |    SubscriberGroup     |
+-------------------------+   +------------------------+
| - name: String          |   | - groupId: String      |
| - messages: List<Msg>   |   | - members: List<Sub>   |
| - subscriptions: List   |   | - offsets: Map         |
| - retentionPolicy       |   +------------------------+
| - currentOffset: Long   |   | + addMember(sub): void |
+-------------------------+   | + getNextConsumer(): Sub|
| + addMessage(msg): void |   | + rebalance(): void    |
| + getMessages(offset,   |   +------------------------+
|     count): List<Msg>   |
| + addSubscription(): void|
+-------------------------+
            |
            | contains
            v
+-------------------------+       +------------------------+
|        Message          |       |     Subscription       |
+-------------------------+       +------------------------+
| - id: String            |       | - subscriber: Sub      |
| - payload: byte[]       |       | - topic: Topic         |
| - timestamp: Long       |       | - filter: Filter       |
| - headers: Map          |       | - offset: Long         |
| - key: String           |       | - groupId: String      |
+-------------------------+       +------------------------+
                                  | + matches(msg): bool   |
                                  | + advance(): void      |
                                  +------------------------+

+-------------------------+       +------------------------+
|       Publisher          |       |      Subscriber        |
+-------------------------+       +------------------------+
| - id: String            |       | - id: String           |
| - name: String          |       | - subscriptions: List  |
+-------------------------+       | - messageQueue: Queue  |
| + publish(topic, msg)   |       +------------------------+
+-------------------------+       | + receive(): Message   |
                                  | + acknowledge(id): void|
                                  +------------------------+

+-------------------------+
|    DeadLetterQueue      |
+-------------------------+
| - messages: List<Msg>   |
| - maxRetries: int       |
+-------------------------+
| + add(msg, reason): void|
| + retry(msg): void      |
| + purge(): void         |
+-------------------------+

---

Design Decisions & Trade-offs

1. Push vs Pull Delivery Model

Decision: Support both - push for real-time subscribers, pull for batch consumers. Default to pull with long-polling for balance.

2. Delivery Semantics

Decision: Default to at-least-once. Provide idempotency support for exactly-once semantics where needed.

3. Message Ordering

Decision: Guarantee ordering within a topic. Use message keys for partition-level ordering when subscriber groups are used.

4. Message Persistence

Decision: In-memory with optional write-ahead log for durability. Configurable per topic.

5. Subscriber Groups (Competing Consumers)

Without Groups (Broadcast):          With Groups (Load Balance):
                                     
Publisher -> Topic -> Sub A           Publisher -> Topic -> Group1 -> Sub A
                  -> Sub B                                        -> Sub B
                  -> Sub C                                        -> Sub C
                                     (only ONE of A/B/C gets each message)
All subscribers get ALL messages      Messages distributed among group members

Decision: Support both modes. Subscribers without a group get all messages (fan-out). Subscribers in a group share the load (competing consumers).

---

Design Patterns Used

---

Edge Cases

---

Extensibility Points

---

Interview Follow-ups

Q&A Style

Q: How would you handle a subscriber that's much slower than the publisher?

A: Multiple strategies depending on requirements:

1. Bounded buffer with backpressure - When subscriber's queue is full, signal publisher to slow down (flow control)
2. Drop policy - Drop oldest messages when buffer is full (acceptable for metrics/monitoring)
3. Persistent overflow - Spill to disk when memory buffer is full, read back when subscriber catches up
4. Subscriber groups - Add more consumers to the group to parallelize processing

The choice depends on whether message loss is acceptable. For critical messages, use persistent overflow + subscriber groups for horizontal scaling.

Q: How do you ensure exactly-once delivery?

A: Exactly-once is achieved through idempotent processing:

1. Broker side - Assign unique message IDs, deduplicate on publish (producer retries don't create duplicates)
2. Consumer side - Track processed message IDs, skip duplicates. Use idempotent operations (e.g., SET vs INCREMENT)
3. Transactional - Atomic commit of message consumption + side effects (e.g., Kafka transactions)

True exactly-once across distributed systems requires end-to-end idempotency, not just broker guarantees.

Q: How would you implement message ordering with multiple consumers in a group?

A: Use key-based partitioning:

1. Messages with the same key always go to the same partition
2. Each partition is consumed by exactly one consumer in the group
3. Ordering is guaranteed within a partition (same key = same consumer = ordered)
4. On rebalancing, pause consumption, reassign partitions, resume from last committed offset

Hints for Self-Practice

Q: How would you design the dead letter queue to be useful for debugging?

• Think about what metadata to capture (original topic, failure reason, retry count, timestamps)
• Consider how operators would inspect and replay messages
• Think about alerting when DLQ grows
• Consider automatic retry with exponential backoff before DLQ

Q: How would you handle schema evolution (publisher changes message format)?

• Think about backward/forward compatibility
• Consider schema registry with version tracking
• Think about how consumers handle unknown fields
• Consider Avro/Protobuf schema evolution rules

---

Counter Questions to Ask Interviewer

• "Should the system support both push and pull delivery, or just one?"
• "What delivery guarantee is required - at-least-once or exactly-once?"
• "Is message ordering critical, or is best-effort acceptable?"
• "Should messages be persisted (survive restarts) or in-memory only?"
• "Do we need subscriber groups (competing consumers) or just broadcast?"
• "What's the expected message throughput and subscriber count?"
• "Should we handle subscriber offline scenarios (message buffering)?"
• "Is there a maximum message retention period?"

---

References

• "Enterprise Integration Patterns" by Gregor Hohpe & Bobby Woolf - Canonical reference for messaging patterns
• Apache Kafka Design - Log-based messaging, partitions, consumer groups (kafka.apache.org/documentation/design)
• RabbitMQ Concepts - Exchange types, queues, bindings, acknowledgments
• "Designing Data-Intensive Applications" by Martin Kleppmann - Chapter 11: Stream Processing
• AMQP 0-9-1 Specification - Protocol-level pub/sub semantics
• "Release It!" by Michael Nygard - Stability patterns for messaging systems
• Kafka: The Definitive Guide (O'Reilly) - Practical implementation patterns
• Paper: "The Log: What every software engineer should know" - Jay Kreps (LinkedIn), 2013

---

Related Topics

• Observer Pattern
• Strategy Pattern
• Producer Consumer Problem
• Thread Safety and Synchronization
• Building Resilient Systems
• All About APIs