Design at-least-once notification delivery

Q: Design at-least-once notification delivery

This question evaluates expertise in reliable distributed systems design, including at-least-once delivery semantics, idempotency and deduplication strategies, retry and dead-letter handling, API and message-schema design, ordering and out-of-order handling, and scalability for high-throughput multi-tenant notification platforms.

Q: 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.

Q: What difficulty level is this interview question?

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

Q: What role is this question designed for?

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

Question

System Design: At-Least-Once Notification System

Context

Design a multi-channel notification platform (email, SMS, push, in-app) that guarantees at-least-once delivery. Duplicates are possible, so the system must be idempotent and provide a good user experience without showing duplicates. Assume high throughput (e.g., thousands of notifications per second), multi-tenant services, and retries across transient failures.

Requirements

High-level architecture and flow that provides at-least-once delivery.
Producer interface (API/SDK) and consumer/worker interface (message schema, ack/nack semantics).
Deduplication strategy: keys, storage, TTL, and uniqueness constraints.
Retry policy with exponential backoff and jitter; failure handling and dead-letter queues.
Out-of-order handling across retries and parallelism; ordering guarantees per key.
User-facing idempotency: ensure no duplicate notifications are displayed to users across channels.

Deliverables

Define producer API (fields, idempotency, responses) and consumer message interface (fields, ack/nack).
Specify deduplication key design and how/where it is stored.
Describe retry algorithm (exponential backoff with jitter), limits, and DLQ behavior.
Describe how to handle out-of-order events (partitioning keys, sequence numbers, buffering windows).
Describe user-facing idempotency for UI and downstream providers (e.g., collapse/replace semantics).
Call out assumptions and trade-offs.

Design at-least-once notification delivery

Quick Overview

Design at-least-once notification delivery

System Design: At-Least-Once Notification System

Context

Requirements

Deliverables

Submit Your Answer to Earn 20XP