Skip to content
sysgeeks

Design a Notification System, stage 9 of 11: change it

Digests and quiet hours

Batching changes notifications from "send when it happens" to "send what accumulated". Evaluate these statements about the new behaviour.

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 2 checks done

  1. A digest replaces "send when it happens" with "periodically, send what accumulated". Two new things need care:

    • The digest itself is a notification, sent by a scheduled job that can run twice, so it needs an identity too, such as (user, issue, hour window).
    • Membership: which notifications went into which digest. If that isn't recorded atomically with the digest, a crash can put one notification in two digests, or in none.

  2. Think first

    A digest job creates the digest record, crashes, and never marks the included notifications as 'in a digest'. The next run starts. What happens?