Design an object-oriented publish/subscribe notification service for user–topic subscriptions. Implement APIs: addSubscription(userId, topicId), unsubscribe(userId, topicId), publishNews(topicId, newsId, payload), and onNewsReceived(userId, newsId) to acknowledge delivery. Ensure each published item is delivered at most once to currently subscribed users, that unsubscribes prevent future deliveries, and provide per-topic per-user ordering guarantees. Describe class/interface design, in-memory and persistence data models, concurrency control, failure handling, and how you would scale to millions of users. Analyze the time and space complexity of core operations.

Design a subscription push service evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Optiver.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Optiver during technical interviews.

Design a subscription push service | Optiver Interview Question

Design a subscription push service

Object-Oriented Design: Publish/Subscribe Notification Service

Design an object-oriented publish/subscribe notification service for user–topic subscriptions.

Provide the following APIs:

addSubscription(userId, topicId)
unsubscribe(userId, topicId)
publishNews(topicId, newsId, payload)
onNewsReceived(userId, newsId) // client acknowledgement

Requirements:

Delivery semantics
- Each published item is delivered at most once to users who are subscribed at the time of delivery.
- Unsubscribes prevent any future deliveries for that user–topic pair, including items published earlier but not yet delivered.
- Per-topic per-user ordering: for a given user and topic, deliver items in the order they were published to that topic.
Design deliverables
- Class/interface design for the service and its components.
- In-memory and persistence data models.
- Concurrency control (ordering, idempotency, race handling).
- Failure handling (restarts, partial failures, retries policy).
- Scalability plan to millions of users.
- Time and space complexity analysis of core operations.

Assume:

newsId is unique per topic (idempotency key).
Per-topic ordering is defined by a monotonically increasing sequence (offset) assigned at publish time.
If a user unsubscribes after a publish but before delivery, do not deliver that item.
New subscriptions start from the current end of the topic (no historical replay).

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Design a subscription push service

Object-Oriented Design: Publish/Subscribe Notification Service

Design an object-oriented publish/subscribe notification service for user–topic subscriptions.

Provide the following APIs:

addSubscription(userId, topicId)
unsubscribe(userId, topicId)
publishNews(topicId, newsId, payload)
onNewsReceived(userId, newsId) // client acknowledgement

Requirements:

Delivery semantics
- Each published item is delivered at most once to users who are subscribed at the time of delivery.
- Unsubscribes prevent any future deliveries for that user–topic pair, including items published earlier but not yet delivered.
- Per-topic per-user ordering: for a given user and topic, deliver items in the order they were published to that topic.
Design deliverables
- Class/interface design for the service and its components.
- In-memory and persistence data models.
- Concurrency control (ordering, idempotency, race handling).
- Failure handling (restarts, partial failures, retries policy).
- Scalability plan to millions of users.
- Time and space complexity analysis of core operations.

Assume:

newsId is unique per topic (idempotency key).
Per-topic ordering is defined by a monotonically increasing sequence (offset) assigned at publish time.
If a user unsubscribes after a publish but before delivery, do not deliver that item.
New subscriptions start from the current end of the topic (no historical replay).

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Design a subscription push service

Quick Overview

Design a subscription push service

Design a subscription push service

Object-Oriented Design: Publish/Subscribe Notification Service

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP

Design a subscription push service

Quick Overview

Design a subscription push service

Design a subscription push service

Object-Oriented Design: Publish/Subscribe Notification Service

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP