+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Notifications: one system, four channels

Cloud By Mits Engineering Team 2 min read
Notifications: one system, four channels

Most products accumulate notification channels rather than designing them. Email came first, SMS was added for OTPs, push arrived with the mobile app, and WhatsApp was bolted on because that is where Indian customers reply. Each was built by whoever needed it, with its own templates, its own sending code and its own idea of when to send. The customer experiences the result as noise, and the business cannot answer basic questions like how many messages we send a person per week.

The fix is a single notification service that owns the decision of what to send, to whom, and through which channel — with the channel providers behind it as interchangeable transports. Application code raises an event: an order shipped, a payment failed, a document is ready. The notification service decides whether that warrants a message, which channel suits it, whether the person has opted out, and whether they have already been told.

Channel choice should follow the message rather than the team that built it. Time-critical and short goes to SMS or push, because that is what they are good at. Anything needing detail, a record, or an attachment goes to email. Conversational follow-up where a reply is likely goes to WhatsApp, which is also where the economics reward you for replying rather than initiating. Authentication codes have their own path with their own reliability requirements. Sending everything everywhere is not thoroughness, it is a failure to decide.

Preferences and suppression belong in the service, not in each channel's code. One place that knows this person has unsubscribed from marketing but still receives transactional messages, has an invalid email, hard-bounced twice, blocked your WhatsApp number, or is inside a quiet-hours window. Products where suppression lives in four systems eventually message someone who asked three times to be left alone, and that is a complaint with regulatory weight behind it in several jurisdictions.

Deduplication and rate limiting are the parts nobody builds until after an incident. A retry loop or a batch job replayed can send the same message hundreds of times to one person, and there is no recovering from that. A per-recipient cap, an idempotency key on every notification, and an absolute daily ceiling are cheap insurance against a category of mistake that damages trust disproportionately to its cause.

Finally, instrument the whole thing centrally. Delivery rate, bounce and failure rate, and engagement, broken down by channel and by message type. That is what tells you a particular SMS template stopped being delivered after someone edited its wording, or that a notification nobody opens is costing money every month. Without a central view, each channel's problems are invisible inside its own dashboard, and the aggregate — how much are we sending, and does any of it work — is a question nobody can answer.

Need help with this? Explore our Cloud Solutions & Migration services. Learn more Back to all news

Keep reading

More on Cloud