Pub/sub pattern in HLD - System Design Exercise

Design: Publish/Subscribe Messaging System

Design the core pub/sub messaging system including message routing, topic management, and delivery guarantees. Out of scope: detailed client SDKs, security/authentication mechanisms, and UI.

Functional Requirements

FR1: Allow multiple publishers to send messages without knowing subscribers

FR2: Allow multiple subscribers to receive messages they are interested in

FR3: Support message filtering by topic or category

FR4: Ensure messages are delivered to all relevant subscribers

FR5: Handle at least 10,000 concurrent publishers and subscribers

FR6: Provide message delivery latency under 200ms (p99)

FR7: Support message persistence for reliability

Non-Functional Requirements

NFR1: System must be highly available with 99.9% uptime

NFR2: Must scale horizontally to handle increasing load

NFR3: Messages should be delivered in near real-time

NFR4: Subscribers should not block publishers

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Message Broker or Broker Cluster

Publisher API

Subscriber API

Topic Manager

Message Queue or Buffer

Delivery Worker or Dispatcher

Persistence Storage for messages

Cache for fast topic lookup

Design Patterns

Fan-out pattern for message distribution

Message queue for buffering

Event-driven architecture

Load balancing across brokers

Backpressure handling for slow consumers

Reference Architecture

  +-------------+       +----------------+       +--------------+
  |  Publishers | ----> | Message Broker | ----> | Subscribers  |
  +-------------+       +----------------+       +--------------+
                             |       ^
                             |       |
                       +-----------+  |
                       | Topic Mgr |--+
                       +-----------+

Components

Message Broker

Kafka / RabbitMQ / Custom Broker

Receives messages from publishers, routes them to subscribers based on topics

Topic Manager

In-memory store or distributed cache (e.g., Redis)

Manages topic subscriptions and metadata

Publisher API

REST/gRPC endpoints

Allows publishers to send messages to topics

Subscriber API

WebSocket / REST / gRPC

Allows subscribers to register interest and receive messages

Message Queue

Broker internal queues

Buffers messages for delivery to subscribers

Persistence Storage

Distributed log or database

Stores messages for durability and replay

Request Flow

1. 1. Publisher sends message to Message Broker via Publisher API specifying topic.

2. 2. Message Broker receives message and stores it in Message Queue and Persistence Storage.

3. 3. Topic Manager identifies subscribers interested in the topic.

4. 4. Message Broker dispatches message to all subscribers registered for the topic.

5. 5. Subscribers receive messages asynchronously via Subscriber API.

6. 6. Acknowledgments from subscribers are optionally processed for delivery guarantees.

Database Schema

Entities: - Topic: id (PK), name - Subscriber: id (PK), connection_info - Subscription: id (PK), subscriber_id (FK), topic_id (FK) - Message: id (PK), topic_id (FK), payload, timestamp Relationships: - One Topic has many Subscriptions - One Subscriber can subscribe to many Topics (many-to-many via Subscription) - Messages belong to one Topic

Scaling Discussion

Bottlenecks

Message Broker CPU and memory limits under high message throughput

Network bandwidth for delivering messages to many subscribers

Topic Manager becoming a single point of failure or bottleneck

Persistence Storage write/read latency under load

Handling slow or offline subscribers causing backpressure

Solutions

Scale Message Broker horizontally with partitioning and clustering

Use load balancers and CDN-like edge nodes for subscriber delivery

Distribute Topic Manager using consistent hashing or sharding

Use high-performance distributed storage (e.g., Kafka logs, Cassandra)

Implement backpressure strategies like message buffering, dropping, or slow consumer detection

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and components, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Clarify delivery guarantees and subscriber types early

Explain how decoupling publishers and subscribers improves scalability

Describe how topics and subscriptions are managed

Discuss message persistence and reliability

Highlight how system scales horizontally and handles failures

Mention trade-offs between latency, consistency, and availability

Practice

1. What is the main purpose of the Pub/Sub pattern in system design?

easy

A. To decouple message senders from receivers for flexible communication

B. To tightly couple components for faster data exchange

C. To store data permanently in a database

D. To encrypt messages for security

Solution

1. Step 1: Understand the role of Pub/Sub

   Pub/Sub pattern separates the sender (publisher) and receiver (subscriber) so they do not depend on each other directly.

2. Step 2: Identify the main benefit

   This separation allows flexible communication and easier scaling of systems.

3. Final Answer:

   To decouple message senders from receivers for flexible communication -> Option A

4. Quick Check:

   Decoupling = A [OK]

Hint: Pub/Sub means senders and receivers don't know each other [OK]

Common Mistakes:

• Thinking Pub/Sub stores data permanently
• Confusing Pub/Sub with encryption
• Assuming tight coupling between components

2. Which of the following is the correct component in a Pub/Sub system?

easy

A. Sender, Receiver, Firewall

B. Client, Server, Database

C. Publisher, Subscriber, Message Broker

D. Producer, Consumer, Cache

Solution

1. Step 1: Recall Pub/Sub components

   Pub/Sub systems have publishers (senders), subscribers (receivers), and a message broker that routes messages.

2. Step 2: Match components to options

   Only Publisher, Subscriber, Message Broker lists these three correctly.

3. Final Answer:

   Publisher, Subscriber, Message Broker -> Option C

4. Quick Check:

   Pub/Sub components = D [OK]

Hint: Remember the broker routes messages between publishers and subscribers [OK]

Common Mistakes:

• Confusing Pub/Sub with client-server terms
• Mixing cache or firewall as core components
• Using generic terms like producer/consumer without broker

3. Consider a Pub/Sub system where a publisher sends messages to a topic. If three subscribers are subscribed to that topic, how many copies of each message does the broker send?

medium

A. One copy shared among all subscribers

B. Three copies, one for each subscriber

C. Zero copies, subscribers pull messages themselves

D. Depends on the message size

Solution

1. Step 1: Understand message delivery in Pub/Sub

   Each subscriber receives its own copy of the message from the broker to ensure independent processing.

2. Step 2: Calculate copies sent

   With three subscribers, the broker sends three copies, one per subscriber.

3. Final Answer:

   Three copies, one for each subscriber -> Option B

4. Quick Check:

   Copies = Subscribers count = B [OK]

Hint: Broker sends one message per subscriber, not shared [OK]

Common Mistakes:

• Assuming one copy shared by all subscribers
• Thinking subscribers pull messages without broker sending
• Believing message size affects copy count

4. A developer implemented a Pub/Sub system but notices subscribers never receive messages. Which is the most likely cause?

medium

A. Subscribers are using the wrong database

B. Publisher is sending messages too frequently

C. Message broker is encrypting messages

D. Subscribers are not subscribed to the correct topic

Solution

1. Step 1: Analyze why subscribers get no messages

   If subscribers never receive messages, a common cause is they are not subscribed to the topic where messages are published.

2. Step 2: Evaluate other options

   Sending frequency or encryption does not prevent delivery; wrong database is unrelated.

3. Final Answer:

   Subscribers are not subscribed to the correct topic -> Option D

4. Quick Check:

   Subscription mismatch = A [OK]

Hint: Check subscriber topic matches publisher topic first [OK]

Common Mistakes:

• Blaming message frequency for delivery failure
• Assuming encryption blocks delivery
• Confusing database usage with Pub/Sub messaging

5. You need to design a scalable notification system using Pub/Sub. Which approach best ensures messages are delivered even if some subscribers are temporarily offline?

hard

A. Use a message broker with persistent storage and durable subscriptions

B. Send messages directly from publisher to subscribers without broker

C. Use a broker that deletes messages immediately after sending

D. Require subscribers to poll the publisher continuously

Solution

1. Step 1: Identify requirements for offline subscriber support

   To handle offline subscribers, messages must be stored until subscribers can receive them.

2. Step 2: Choose the right Pub/Sub feature

   Persistent storage and durable subscriptions in the broker ensure messages are saved and delivered later.

3. Step 3: Evaluate other options

   Direct sending or immediate deletion loses messages; polling is inefficient and not scalable.

4. Final Answer:

   Use a message broker with persistent storage and durable subscriptions -> Option A

5. Quick Check:

   Durable subscriptions = reliable delivery = C [OK]

Hint: Durable subscriptions keep messages for offline subscribers [OK]

Common Mistakes:

• Skipping message persistence in broker
• Trying direct publisher-to-subscriber without broker
• Relying on polling instead of push delivery