Case Studies
Notification System
Turning events into multi-channel notifications without ever double-sending, under at-least-once delivery.
Designing a service that turns internal events ("someone liked your post") into notifications delivered across channels — push and email — while respecting user preferences and never double-sending for the same event.
Think of this system as a mailroom, not a courier. Other services in the company hand it a memo — "someone liked your post" — and the mailroom's job is figuring out which of that user's addresses to send it to, based on standing instructions the user already gave. Nobody's timing the mailroom with a stopwatch; they're checking, months later, whether a letter ever went missing.
What this lesson covers
Producers publish events to Kafka; workers check user preferences, dedup on a short-TTL Redis key (eventId + userId + channel) since delivery is at-least-once, and enqueue per-channel delivery to APNs/FCM or email. A few seconds of lag buys never blocking the event source.
- This is a mailroom, not a courier: durability matters more than sub-second delivery, and a lost notification is the real failure.
- Turn internal events into push and email per user preferences, and never send the same notification twice under retries.
- Producers must not call the notification path synchronously, or a slow channel backs up the service that raised the event.
- Retries make duplicate delivery a real risk; a senior answer proposes the dedup check before being asked.
- A staff answer keeps one degraded provider (say, push) from stalling email, and treats transient and permanent failures differently.
Included in Plus and Pro
Continue reading “Notification System”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 19 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself