Design a Notification System, stage 4 of 11: decide
When are preferences applied?
A user turns off comment emails. Notifications already planned for them are sitting in a queue behind an announcement and may not be sent for an hour. The requirement says preference changes take effect immediately.
System so far· 4 parts
Select a component to see what it is responsible for and which state it owns.
- 1Product services → Event stream: Domain events via outbox
- 2Event stream → Notification planner: Events, at least once
- 3Notification planner → Notifications DB: Insert notifications under dedupe keys
- Asynchronous
- Request / response
What you need to know
A notification is planned at one moment and sent at another. Normally the gap is seconds. Behind a large announcement, or during a provider outage, it can be an hour.
Anything decided at planning time can be out of date by sending time. The question is which decisions must be checked again just before the irreversible step.
Think first
A user turns off comment emails at 10:00. Three comment emails for them were planned at 09:55 and are queued behind an announcement until 10:40. If preferences are checked only at planning time, what happens?There are good reasons to check at planning time as well. At fan-out scale, not creating unwanted deliveries saves work in every queue and sender.
When a send-time check cancels a delivery, record it as suppressed rather than deleting it. Support can then answer "why didn't I get this?" from the record.
Check
Senders read preferences on every send. To save database load, should they cache them for an hour?