Back to BlogEngineering

How We Built Real-Time Response Notifications

Alex RiveraApril 27, 20267 min read
How We Built Real-Time Response Notifications

Real-time notifications sound like a straightforward feature — send a push or email when a response arrives — but doing it well requires balancing immediacy against notification fatigue.

Event-Driven Foundation

Every new response publishes an event to an internal message queue, decoupling notification delivery from the response submission itself. This means a slow or failing notification provider never delays or blocks the actual survey submission experience.

Configurable Alert Rules

Rather than notifying on every single response — which quickly becomes noise for high-volume surveys — customers configure rules: notify immediately for low ratings (potential churn risk), batch daily for neutral or positive responses, and allow muting entirely for specific surveys.

Multi-Channel Delivery

Notifications route to email, browser push, or webhook depending on customer preference, with the same underlying event triggering all three simultaneously if configured. Each channel has its own delivery confirmation and retry logic independent of the others.

Deduplication Windows

If a customer configures both "notify on low rating" and "notify on negative sentiment," and a single response triggers both rules, we deduplicate into a single notification rather than sending two separate alerts for the same event.

Respecting Quiet Hours

Time-sensitive alerts (like a critical low rating) still go out immediately, but non-urgent digest notifications respect the customer's configured working hours and timezone, batching overnight activity into a single morning summary rather than a 2am ping.

Handling Notification Provider Outages

Email and push notification providers occasionally experience their own outages, and a naive integration would simply drop notifications during that window. We queue notifications with a retry policy independent of the underlying delivery event queue, so a temporary provider outage results in delayed — not lost — notifications, with automatic catch-up once the provider recovers.

The goal of a notification system isn't to notify as often as technically possible — it's to make sure the right person sees the right feedback at the moment it's actually useful to act on it.

AR
Alex Rivera
AItocha Surveys