# Design a publish-subscribe service like Google Pub/Sub: system design interview question

> Durable event delivery with independent subscription progress, acknowledgment recovery, and limits for slow subscriptions.

Source: https://sysround.com/questions/design-publish-subscribe-service-like-google-pub-sub
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a topic-based publish-subscribe service with independent subscriptions. The service must provide durable delivery and acknowledgments. Slow subscriptions must not disrupt other subscriptions."

## What to clarify first

- Scale
- Event size and traffic mix
- Delivery behavior
- Subscription creation
- Latency
- Durability
- Consistency versus availability
- Retention
- Slow subscriptions
- Scope boundaries

## Scope of a strong answer

Core requirements:

- Create topics and independent durable subscriptions
- Publish events with a durable acceptance response
- Pull events, acknowledge them, and retry unacknowledged events
- Isolate slow subscriptions from healthy subscriptions

Usually out of scope:

- Exactly-once effects in subscriber applications
- Push delivery to external endpoints
- Cross-region replication
- Historical replay before subscription creation
- Subscription filters

## What interviewers probe

### Event acceptance

The service must preserve accepted events without a separate durable payload write for every subscription.

### Delivery and acknowledgments

Concurrent acknowledgments create gaps in subscription progress. One persistent gap can cause completed-event state to grow without limit.

### Slow subscriptions

Independent progress does not prevent resource contention. Slow subscriptions can exhaust delivery memory, read capacity, or retained storage.

### Expired events

Expiry removes payload before a subscriber receives it. Later expiry must not disappear when the client confirms an earlier gap notice.

## Common mistakes

- Uses one shared cursor for independent subscriptions, so subscribers divide events instead of each receiving them.
- Confuses durable acceptance with subscriber delivery.
- Advances progress past unacknowledged events without preserving their state.
- Bounds active deliveries but leaves completed-event state unbounded behind a persistent gap.
- Lets an older gap confirmation discard newly expired ranges that the client never received.
- Ignores delivery bandwidth, ack traffic, or retention limits when estimating capacity.

## The bar by level

- **Senior:** Proves publish and ack recovery across failures. Bounds completion state and explains when delivery pauses. Preserves gap coverage across confirmations. Enforces subscriber isolation.
- **Staff+:** Defines guarantees across event storage, metadata, and progress ownership. Quantifies state limits, recovery capacity, and retention costs. Proves gap recovery and quota enforcement during overload.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=publish-subscribe


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.