Skip to content
Nexus Docs

Notifications

Notifications flow through a single pipeline: an event is resolved to an audience, filtered by per-recipient preferences, and fanned out to channels. Full design: docs/notifications-architecture-plan.md.

Model

Section titled “Model”
  • Event types are dot-delimited canonical keys (e.g. booking.confirmed).
  • Preferences are stored at the finest grain: per (recipient, event_type, channel).
  • Default is opt-in — no preference row (or active=false) means that channel does not fire. Transactional defaults can be seeded per role.
  • Channels are pluggable — email and SMS today; in_app (inbox + bell); push is a documented slot, not yet implemented.

Transport

Section titled “Transport”

The existing BullMQ queue is the transport (the equivalent of an event bus + processor). Recipient resolution, preferences, and channel fan-out are the layer on top.

Code

Section titled “Code”

apps/scheduler-api/src/modules/notifications/ — dispatch, audience, catalog, preferences, channels, seed-defaults, inbox / admin-inbox.

See the Notifications flow for the runtime sequence.