Description

Editorial

Design a Pub Sub System

Intermediate

Design an object-oriented publish-subscribe messaging system where publishers send messages to named topics and subscribers receive those messages either via push (immediate notification) or pull (offset-based polling).

The system should support topic management, subscriber registration with independent offset tracking, subscription pause/resume, and message filtering. The broker acts as a mediator between publishers and subscribers.

Core Use Cases

Create and delete topics

Subscribe to a topic

Subscribers register interest in a topic and receive messages

Unsubscribe from a topic

Remove a subscriber from a topic's notification list

Publish a message

Publishers send messages to a topic; all active subscribers are notified (push model)

Poll for messages

Subscribers pull the next unread message using an offset-based cursor (pull model)

Pause and resume subscriptions

Temporarily halt delivery without losing the subscriber's position

Message filtering

Some subscribers only process messages matching a predicate

Constraints

Messages are delivered to all active subscribers of a topic
Each subscriber tracks its own offset independently (no shared cursor)
Publishing to a non-existent topic is an error
A subscriber can subscribe to multiple topics
Messages are ordered by publish time within a topic

Assumptions

In-memory storage (no disk persistence)
Single-threaded execution (thread-safety is a follow-up)
Messages are not deleted after consumption (log-based retention)
No message acknowledgment / retry mechanism (follow-up topic)

In Scope

Topic management (create, delete, list)
Subscriber registration and unregistration
Push-based delivery (notify on publish)
Pull-based delivery (poll with offset)
Subscription pause/resume
Message filtering at the subscriber level

Out of Scope

Persistent storage and replay from disk
Distributed brokers and partitioning
Message acknowledgment and dead-letter queues
Schema registry / message serialisation (Avro, Protobuf)
Authentication and access control per topic

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

UML

Code

Submissions

Solutions

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

Description

Editorial

Design a Pub Sub System

Intermediate

Core Use Cases

Create and delete topics

Subscribe to a topic

Subscribers register interest in a topic and receive messages

Unsubscribe from a topic

Remove a subscriber from a topic's notification list

Publish a message

Publishers send messages to a topic; all active subscribers are notified (push model)

Poll for messages

Subscribers pull the next unread message using an offset-based cursor (pull model)

Pause and resume subscriptions

Temporarily halt delivery without losing the subscriber's position

Message filtering

Some subscribers only process messages matching a predicate

Constraints

Messages are delivered to all active subscribers of a topic
Each subscriber tracks its own offset independently (no shared cursor)
Publishing to a non-existent topic is an error
A subscriber can subscribe to multiple topics
Messages are ordered by publish time within a topic

Assumptions

In-memory storage (no disk persistence)
Single-threaded execution (thread-safety is a follow-up)
Messages are not deleted after consumption (log-based retention)
No message acknowledgment / retry mechanism (follow-up topic)

In Scope

Topic management (create, delete, list)
Subscriber registration and unregistration
Push-based delivery (notify on publish)
Pull-based delivery (poll with offset)
Subscription pause/resume
Message filtering at the subscriber level

Out of Scope

Persistent storage and replay from disk
Distributed brokers and partitioning
Message acknowledgment and dead-letter queues
Schema registry / message serialisation (Avro, Protobuf)
Authentication and access control per topic

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

UML

Code

Submissions

Solutions

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design a Pub Sub System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add message acknowledgment and retry for failed deliveries?

2How would you make this thread-safe for concurrent publishers and subscribers?

3How would you add consumer groups (like Kafka) where only one subscriber in a group gets each message?

4How would you implement message expiration / retention policies?

5How would you support wildcard topic subscriptions (e.g., 'orders.*')?

Key Topics

Asked At

Design a Pub Sub System

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you add message acknowledgment and retry for failed deliveries?

2How would you make this thread-safe for concurrent publishers and subscribers?

3How would you add consumer groups (like Kafka) where only one subscriber in a group gets each message?

4How would you implement message expiration / retention policies?

5How would you support wildcard topic subscriptions (e.g., 'orders.*')?

Key Topics

Asked At