Notification Hub (UCNS)
2025
Centralized notification platform — ingest → templating → per-channel dispatch (SMS / mobile / web) with persist-before-dispatch invariants, bounded retry, and per-channel queue isolation.
The problem
Citizens receive notifications about licences, fee deadlines, and service status from many different Balady services. Without a hub, every service implements SMS / push / web-toast itself — inconsistent templates, no central rate-limit, no shared retry semantics, no audit.
The architecture
A four-stage pipeline:
- Ingest — producer services publish a notification request (recipient, template id, channel preferences, locale).
- Templating — the Product Notifier renders the request through the appropriate template; localised content + dynamic substitution.
- Persist-before-dispatch — the rendered notification is written to the MongoDB notification store before dispatch attempts begin. This guarantees we never deliver-and-forget; every send has a durable record.
- Per-channel dispatch — separate RabbitMQ queues per channel (SMS, mobile push, web). Channel-level back-pressure cannot poison other channels.
Bounded retry (max 10 attempts) per notification, with exponential backoff between attempts. Failures are flagged in the store for operations review.
Outcome
One notification model for the entire Balady ecosystem. Per-channel queue isolation means an SMS-vendor outage doesn’t slow push notifications, and vice versa.