← All work
01 · Messaging · 2026 · Work

Notification System

A centralized notification system with in-app and email delivery, and per-user preferences so recipients control what they get and which channel it arrives on.

ANY FEATUREMESSAGE ENGINECHANNELSLoad eventsDocumentsIntegrationsNotificationserviceROUTE BY TYPECHECK PREFERENCESRABBITMQPreferencesPER USER · PER TYPEIn-appSIGNALR · ON BY DEFAULTEmailPER PREFERENCENext channelNEEDS A NEW COLUMN TODAYPUBLISH ONCE · DELIVER PER PREFERENCE

The problem

Notifications were handled individually across features, with no central place to manage delivery. In-app was the only channel a user could receive, and they had no say in what reached them or how. The client kept that list fresh by polling the full notification table every two minutes, which added steady server load and timeouts for users with a large backlog.

What was built

One notification system used across the entire app, publishing notifications via the message engine.

◆In-app and email channels, with individual routing by notification type.
◆Per-user preferences control which channel handles which notification type.
◆In-app delivery defaults to on for every type, so notifications work out fo the box for a user who has not set preferences yet.
◆Replaced polling with a SignalR hub, so clients get notifications the moment they are sent instead of re-fetching the whole list on a timer.
◆Result: a pattern every feature used to re-implement became a single reusable call, the polling load and its timeouts went away, and users decide what reaches them and where.

What I'd do differently

I would normalize the preferences schema so additional channels drop in cleanly. Today adding a channel means adding a column - it works, but it does not scale.