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.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale
- Event size and traffic mix
- Delivery behavior
- Subscription creation
- Latency
- Durability
- Consistency versus availability
- Retention
- Slow subscriptions
- Scope boundaries
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
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 ask about
- 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 (L5/E5)
- Proves publish and ack recovery across failures. Bounds completion state and explains when delivery pauses. Preserves gap coverage across confirmations. Enforces subscriber isolation.
- Staff (L6+/E6+)
- 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.