05.03 · Concept
Preferences, Frequency & State
Store notification preference as first-class user state, and implement digesting and quiet hours without losing a message.
Notification preferences belong in durable user state, separate from the code that creates notifications. Store channel choices, topics, frequency, quiet hours and opt-outs centrally, then let delivery workers decide whether to send, defer, digest, expire or suppress each message without silently losing important events.
What this lesson answers
- how to store notification preferences as user state
- how to implement quiet hours without dropping notifications
- how to design notification digests and delivery state
Notes
Notification preferences should be treated as product state, not as a UI setting or an afterthought inside a send function. A user’s channel choices, topics, frequency, quiet hours, and opt-outs should live in durable storage with clear ownership, validation, auditability, and defaults. The notification pipeline should read that state when deciding when and how to deliver, rather than scattering preference checks across many callers.
The useful mental model is to separate message creation from message delivery. When something happens, create a durable notification or notification-intent record…
References
Common questions
- Should notification preferences live in the sender code?
- No. Preferences should be stored as durable product state with clear ownership, validation, defaults and auditability. Sender code should create a notification intent, not decide every delivery rule itself. A separate delivery path can then apply channel preferences, quiet hours, digests, opt-outs and expiry consistently.
- What should happen during a user's quiet hours?
- Quiet hours should defer delivery, not erase the notification. If the message is still relevant, keep it queued or stored until it can be sent or grouped into a digest. If it should no longer be sent, record an explicit expiry, supersession or suppression decision instead of losing it implicitly.
- How do digests change notification system design?
- Digests require separating event capture from delivery timing. Each notification intent is recorded when the event occurs, then later selected, grouped and sent according to the user's frequency settings. This makes retries, duplicate prevention, preference changes and audit trails easier to reason about than scattered send-time checks.
Short definition: what is Preferences, Frequency & State?