What's the volume - events ingested/sec, notifications delivered/sec at peak?

1M events ingested/sec at peak. 100M users with avg 10 subscriptions each. Average fanout 100x → 100M deliveries/sec gross; after preference filtering, ~10M deliveries/sec actual. Burstable to 10x for product launches.

What's the latency expectation - sub-second for in-app, minutes for digest emails?

In-app push p99 < 5 seconds end-to-end (event ingested → user sees notification on connected device). Email/SMS p99 < 60 seconds (network transit + provider queue). Digest emails: hourly or daily, on schedule.

gitGood.dev

Messaging

Design a Notifications / Pub-Sub System (Kafka / SNS / SQS)

Hard Premium

Fan-out at write vs read, at-least-once vs exactly-once, dead-letter queues, and the multi-channel delivery problem - one message, ten failure modes.

The problem

Design a notifications platform that ingests events from many producers and delivers them to many consumers across multiple channels (in-app, push, email, SMS, webhook). Producers don't know who the consumers are; consumers don't know who the producers are. The platform handles delivery guarantees, retries, user preferences, throttling, and back-pressure invisibly.

This problem has two layers: the pub-sub messaging substrate (Kafka / SNS / SQS) and the notifications product on top (per-user fan-out, channel selection, preferences, deliverability). Strong candidates separate these concerns explicitly and discuss the trade-offs at each layer.

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→What's the volume - events ingested/sec, notifications delivered/sec at peak?
→What channels - in-app only, or also push (APNs/FCM), email (SES/SendGrid), SMS (Twilio), webhooks?
→What delivery guarantees - at-most-once, at-least-once, exactly-once?
→How are subscriptions defined - per-user preferences, per-topic, server-side rules engine?
→What's the latency expectation - sub-second for in-app, minutes for digest emails?
→Multi-tenant - one notification platform serving many product teams?
→Compliance constraints - email unsubscribe (CAN-SPAM), SMS opt-in (TCPA), GDPR consent?
→What's the fanout factor - 1:1 (transactional), 1:N (one event → many users), or 1:millions (broadcast)?

Requirements

Functional requirements

·POST /events - producer publishes an event with a topic + payload
·Subscribe consumers (user_id + channels + filters) to topics
·Deliver events to subscribed consumers' chosen channels
·Per-user preferences (mute topic, quiet hours, frequency caps)
·Retry failed deliveries with exponential backoff
·Dead-letter queue for permanently undeliverable messages
·Delivery audit log (when was the event sent, did it succeed, did the user see it)

Non-functional requirements

Scale: 1M events ingested/sec at peak. 100M users with avg 10 subscriptions each. Average fanout 100x → 100M deliveries/sec gross; after preference filtering, ~10M deliveries/sec actual. Burstable to 10x for product launches.
Latency: In-app push p99 < 5 seconds end-to-end (event ingested → user sees notification on connected device). Email/SMS p99 < 60 seconds (network transit + provider queue). Digest emails: hourly or daily, on schedule.
Availability: 99.95% for ingestion (producers should never be blocked). 99.9% for delivery (downstream channels have their own reliability). The platform must absorb provider outages (Twilio down) without losing events.
Consistency: At-least-once delivery is the default. Producers and consumers must be idempotent on event_id. Event ordering within a (user, topic) is preserved; cross-topic ordering is not guaranteed.

The full walkthrough covers

Architecture components

·Event ingestion API
·Durable event log (Kafka)
·Subscription registry
·Fan-out service
·Channel delivery queues (SQS / Kafka topics)
·Channel workers
·Connection gateway (in-app)
·Dead-letter queue (DLQ)
·Preference + throttling service
·Audit / observability pipeline

Deep dives

Fanout-on-write vs fanout-on-read
Delivery guarantees: at-least-once is the right answer
Multi-channel delivery: push, email, SMS, webhook, in-app
Back-pressure, dead-letter queues, and graceful degradation
User preferences, quiet hours, and frequency capping
Ordering, partitioning, and the consumer scaling problem

What's in the full walkthrough

Capacity estimation · architecture with all 10 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions

This system design walkthrough is part of Premium

Unlock it with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

Every system design walkthrough - capacity estimates, deep dives and trade-offs
Full-length AI mock interviews - 3 to 10 questions with follow-ups, up to 3 a day

View Plans

7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). Cancel anytime.

Companies that test this topic

Practice in interview format

Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.

Mock interview: design Notifications →

Messaging

Design a Notifications / Pub-Sub System (Kafka / SNS / SQS)

Hard Premium

Fan-out at write vs read, at-least-once vs exactly-once, dead-letter queues, and the multi-channel delivery problem - one message, ten failure modes.

The problem

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→What's the volume - events ingested/sec, notifications delivered/sec at peak?
→What channels - in-app only, or also push (APNs/FCM), email (SES/SendGrid), SMS (Twilio), webhooks?
→What delivery guarantees - at-most-once, at-least-once, exactly-once?
→How are subscriptions defined - per-user preferences, per-topic, server-side rules engine?
→What's the latency expectation - sub-second for in-app, minutes for digest emails?
→Multi-tenant - one notification platform serving many product teams?
→Compliance constraints - email unsubscribe (CAN-SPAM), SMS opt-in (TCPA), GDPR consent?
→What's the fanout factor - 1:1 (transactional), 1:N (one event → many users), or 1:millions (broadcast)?

Requirements

Functional requirements

·POST /events - producer publishes an event with a topic + payload
·Subscribe consumers (user_id + channels + filters) to topics
·Deliver events to subscribed consumers' chosen channels
·Per-user preferences (mute topic, quiet hours, frequency caps)
·Retry failed deliveries with exponential backoff
·Dead-letter queue for permanently undeliverable messages
·Delivery audit log (when was the event sent, did it succeed, did the user see it)

Non-functional requirements

Scale: 1M events ingested/sec at peak. 100M users with avg 10 subscriptions each. Average fanout 100x → 100M deliveries/sec gross; after preference filtering, ~10M deliveries/sec actual. Burstable to 10x for product launches.
Latency: In-app push p99 < 5 seconds end-to-end (event ingested → user sees notification on connected device). Email/SMS p99 < 60 seconds (network transit + provider queue). Digest emails: hourly or daily, on schedule.
Availability: 99.95% for ingestion (producers should never be blocked). 99.9% for delivery (downstream channels have their own reliability). The platform must absorb provider outages (Twilio down) without losing events.
Consistency: At-least-once delivery is the default. Producers and consumers must be idempotent on event_id. Event ordering within a (user, topic) is preserved; cross-topic ordering is not guaranteed.

The full walkthrough covers

Architecture components

·Event ingestion API
·Durable event log (Kafka)
·Subscription registry
·Fan-out service
·Channel delivery queues (SQS / Kafka topics)
·Channel workers
·Connection gateway (in-app)
·Dead-letter queue (DLQ)
·Preference + throttling service
·Audit / observability pipeline

Deep dives

Fanout-on-write vs fanout-on-read
Delivery guarantees: at-least-once is the right answer
Multi-channel delivery: push, email, SMS, webhook, in-app
Back-pressure, dead-letter queues, and graceful degradation
User preferences, quiet hours, and frequency capping
Ordering, partitioning, and the consumer scaling problem

What's in the full walkthrough

Capacity estimation · architecture with all 10 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions

This system design walkthrough is part of Premium

Unlock it with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

Every system design walkthrough - capacity estimates, deep dives and trade-offs
Full-length AI mock interviews - 3 to 10 questions with follow-ups, up to 3 a day

View Plans

7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). Cancel anytime.

Companies that test this topic

Practice in interview format

Mock interview: design Notifications →

Design a Notifications / Pub-Sub System (Kafka / SNS / SQS)

The problem

Clarifying questions

Requirements

Functional requirements

Non-functional requirements

The full walkthrough covers

Architecture components

Deep dives

What's in the full walkthrough

This system design walkthrough is part of Premium

Start Your 7-Day Trial

Related system design topics

Chat

Rate Limiter

Companies that test this topic

Practice in interview format

Design a Notifications / Pub-Sub System (Kafka / SNS / SQS)

The problem

Clarifying questions

Requirements

Functional requirements

Non-functional requirements

The full walkthrough covers

Architecture components

Deep dives

What's in the full walkthrough

This system design walkthrough is part of Premium

Start Your 7-Day Trial

Related system design topics

Chat

Rate Limiter

Companies that test this topic

Practice in interview format