Unify Notification Services Without Duplicate Delivery

# Unify Notification Services Without Duplicate Messages Two existing notification systems each own a different notification type and integrate with only one delivery platform. Design one service that supports multiple notification types and platforms while ensuring a user does not receive the same logical message twice. Cover migration, identity, preference enforcement, retries, provider callbacks, and observability. ### Constraints & Assumptions - Producers and queues may retry, and delivery providers may return ambiguous timeouts. - One logical notification can have email, push, SMS, or in-app renderings. - Users can change preferences or contact endpoints. - The two legacy systems cannot be switched off simultaneously. - Some channels cannot guarantee exactly-once external delivery. ### Clarifying Questions to Ask - What makes two requests the same logical notification? - Is deduplication per user, event, type, channel, or a time window? - Which messages are mandatory, and which obey opt-out or quiet-hour rules? - What delivery and freshness guarantees does each provider offer? ### What a Strong Answer Covers - A canonical notification request and stable idempotency identity - Durable orchestration state, outbox ingestion, and channel-specific attempts - Atomic deduplication before dispatch plus safe retry and callback handling - Preferences, templates, platform adapters, rate limits, and audit - Shadow or dual-read migration with reconciliation and rollback ### Follow-up Questions 1. How do you handle a provider timeout when the message may already have been delivered? 2. How would you merge two legacy dedupe-key formats without suppressing valid messages? 3. Which guarantees can the service honestly promise for SMS? ```hint Deduplicate logical intent before channel delivery Give every user-notification intent a stable idempotency key, then track each channel attempt separately under that durable record. ```