Q: How do you deduplicate notifications to prevent sending the same alert twice?

Each NotificationRequest has an idempotency_key — a business-level identifier like "order_shipped:{order_id}" or "friend_joined:{user_id}:{friend_id}". Before processing: SELECT 1 FROM NotificationRequest WHERE idempotency_key=X. If a row exists, skip. If not, insert with status='pending' — using INSERT ... ON CONFLICT (idempotency_key) DO NOTHING to handle races between concurrent workers. This database-level dedup survives Kafka message duplication and consumer restarts. The idempotency_key must be constructed by the event producer — the notification service cannot infer it. For timed notifications (daily digest), use "daily_digest:{user_id}:{date}" as the key.

Question 1

How does a frequency cap prevent notification fatigue?

Accepted Answer

Frequency caps limit how many notifications a user receives per channel per time window — e.g., at most 3 push notifications per day, 1 email per hour, 5 in-app alerts per 24 hours. Without caps, a burst of upstream events (10 friends joined at once, 5 orders shipped) generates 10+ notifications in seconds, causing users to disable all notifications. Implementation: a NotificationFrequency table (user_id, channel, window_start, count). Before dispatching: SELECT count FROM NotificationFrequency WHERE user_id=X AND channel=Y AND window_start >= NOW()-interval. If count >= limit, enqueue for the next window instead of sending now. Use INSERT ... ON CONFLICT (user_id, channel, window_start) DO UPDATE SET count = count + 1 to atomically increment the counter. Hourly windows reset automatically as window_start shifts.

Question 2

How do you handle quiet hours across different user timezones?

Accepted Answer

Quiet hours (e.g., no notifications between 10pm and 8am local time) must be enforced in the user's local timezone, not UTC. Store user_timezone as an IANA timezone string (America/New_York, Asia/Tokyo). At dispatch time: compute the user's local hour using their timezone. If current local hour falls in the quiet window, don't send — instead, enqueue the notification for delivery at the quiet hours end time (8am local = 8am user_tz converted to UTC). Use Python's datetime.now(ZoneInfo(user_timezone)) to get the local time. For users with no timezone set, use UTC as the default or prompt them to set it during onboarding. Quiet hours for marketing notifications; urgent notifications (security alerts) bypass quiet hours with a notification_priority field.

Question 3

How do you route a notification to the right channel based on user preferences?

Accepted Answer

NotificationPreference table stores (user_id, notification_type, channel, is_enabled) per notification category. A notification_type might be "order_shipped" — some users want email only, others want push + email, others have turned it off entirely. The dispatch function filters by preference before sending: fetch all preferences for (user_id, notification_type), iterate over channels where is_enabled=TRUE. If no preference rows exist, use the system default (send via push if the user has a push token). Channel priority: if a push token is not registered (user hasn't used the mobile app), fall back to email. Log which channel was used in NotificationDelivery for analytics: "80% of order_shipped notifications are delivered via email because only 20% of users have push tokens."

Question 4

How do you implement exponential backoff retry for failed notification deliveries?

Accepted Answer

Each channel worker (push, email, SMS) wraps the external API call in a retry loop with exponential backoff. Retry schedule: attempt 1 at T+0, attempt 2 at T+30s, attempt 3 at T+2m, attempt 4 at T+8m, attempt 5 at T+32m, then give up and mark as "failed." Store retry_count and next_attempt_at in NotificationDelivery. A background worker queries: SELECT * FROM NotificationDelivery WHERE status='retrying' AND next_attempt_at <= NOW(). On each retry failure: UPDATE SET retry_count=retry_count+1, next_attempt_at=NOW() + interval '30 seconds' * power(4, retry_count). Max retries = 5; after that set status='failed' and trigger an alert if failure rate exceeds 5% of a notification type.

Question 5

How do you deduplicate notifications to prevent sending the same alert twice?

Accepted Answer

Each NotificationRequest has an idempotency_key — a business-level identifier like "order_shipped:{order_id}" or "friend_joined:{user_id}:{friend_id}". Before processing: SELECT 1 FROM NotificationRequest WHERE idempotency_key=X. If a row exists, skip. If not, insert with status='pending' — using INSERT ... ON CONFLICT (idempotency_key) DO NOTHING to handle races between concurrent workers. This database-level dedup survives Kafka message duplication and consumer restarts. The idempotency_key must be constructed by the event producer — the notification service cannot infer it. For timed notifications (daily digest), use "daily_digest:{user_id}:{date}" as the key.

Notification Dispatch System Low-Level Design: Multi-Channel Routing and Preferences

Core Data Model

Dispatch Pipeline

Channel Send Workers

Key Interview Points