Skip to content
sysgeeks

Design a Notification System, stage 11 of 11: defend it

Defend the duplicate policy

The product manager asks for a simple promise in the help centre: "We never send the same notification twice." Explain what you can promise, what you cannot, and why.

System so far· 10 parts
123456789SERVICEProduct servicesLOG / STREAMEvent streamWORKERNotificationplannerDATABASENotifications DBQUEUEDelivery queuesWORKERChannel sendersEXTERNALEmail providerEXTERNALPush servicesSERVICEInbox APICLIENTWeb andmobile apps

Select a component to see what it is responsible for and which state it owns.

  1. 1Product services → Event stream: Domain events via outbox
  2. 2Event stream → Notification planner: Events, at least once
  3. 3Notification planner → Notifications DB: Insert notifications under dedupe keys
  4. 4Notification planner → Delivery queues: Deliveries by priority class
  5. 5Channel senders → Delivery queues: Claim deliveries
  6. 6Channel senders → Email provider: Send within quota
  7. 7Channel senders → Push services: Send to each device
  8. 8Web and mobile apps → Inbox API: Inbox and read state
  9. 9Inbox API → Notifications DB: Read notifications
  • Asynchronous
  • Request / response

What you need to know

0 of 1 checks done

  1. Explaining a guarantee to a non-engineer comes down to three plain statements:

    • What we guarantee, in terms of what the person sees.
    • What we can't, and the one concrete situation where it happens.
    • What we chose in that situation, and why it's the better failure for them.

    Avoid words like "idempotent" or "at least once". Describe the outcome.

  2. Check

    Which public promise stays true during incidents?