Skip to content
← Back to blog

Blog

Building notification systems

March 18, 2026 · Boson

engineeringarchitecture

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:

  1. Know the subscriber id
  2. Decide which channel to use for that moment
  3. 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.