akshay931/distri_notification_and_alert_system

Purpose and Entry Point

A Node.js/Express distributed notification backend for ingesting, processing, scheduling, and delivering Email, SMS, and Push alerts. The application entry point is src/server.js, exposing /notify for notification submission and /analytics for delivery metrics.

Runtime and Deployment Boundary

The system uses Node.js with Express, Kafka for asynchronous service decoupling, MongoDB through Mongoose for persistent state, and node-schedule for deferred work. Container orchestration is defined by Dockerfile and docker-compose.yml; Kafka and MongoDB are material infrastructure dependencies.

Ingestion Stage

services/notificationIngestion.js receives and validates notification requests from the API layer before publishing accepted work to the Kafka notifications topic. This isolates synchronous client handling from downstream processing and delivery latency.

Processing and Scheduling Engine

services/notificationProcessing.js consumes notification work, classifies urgent/high-priority versus deferred messages, and applies delivery eligibility rules. Scheduled notifications are persisted and revisited through the scheduling runtime rather than delivered directly.

Core policy queries are separated from orchestration:

• queries/throttling.js

• queries/quietHours.js

• queries/deduplication.js

• queries/aggregation.js

• queries/urgentAlerts.js

These rules determine whether a notification is immediately delivered, suppressed, combined, or rescheduled.

Persistent Domain Model

MongoDB documents define the key state boundary:

• models/notification.js stores notification lifecycle data, scheduling, delivery status, retries, and likely audit information.

• models/user.js holds recipient preferences such as channel choices, quiet hours, and rate limits.

Processing reads user policy and notification history from this persistence layer to make rule-driven decisions.

Delivery and Reliability

services/notificationDelivery.js performs channel delivery through mock Email/SMS/Push integrations. It records delivery outcomes in MongoDB and retries failed attempts, separating transport-specific failure handling from policy evaluation in the processor.

The intended flow is: API request → Kafka publication → processing/rules → immediate or scheduled delivery → persisted status and retry updates.

Analytics Surface

services/analytics.js aggregates persisted notification and delivery records for the /analytics API. Analytics is a read-oriented boundary for delivery success, retries, and engagement/operational metrics, rather than part of the delivery critical path.