Blog
Building notification systems
March 18, 2026 · Boson
Most products do not need a custom notification stack. They need a clear boundary: your app emits events, something else stores them, and channels deliver when ready.
Keep the product thin
Your application should:
- Know the subscriber id
- Decide which channel to use for that moment
- Call one events API with a title and body
Everything else - persistence, read state, sockets, retries - belongs outside the product UI.
One worker, many handlers
Boson routes each event through a registered channel handler. In-app writes the inbox and publishes on Redis for the WebSocket. Email, SMS, and push call their provider when credentials exist.
That keeps channel work pluggable. You do not fork the inbox every time you add SMS.
Failures belong in the log
Delivery status should live next to the notification, not only in provider dashboards. When a send fails, the worker records it so the console stays the source of truth for “what did we try?”
If you are wiring this up for the first time, start with in-app only. Add email when an address is on the subscriber and a provider is configured.