Applications need to send important messages quickly and reliably — that’s the problem Sandesh was built to solve.

Push notifications, email, and SMS all land in one delivery layer, so individual products don’t need to manage queues, retries, schedules, templates, or provider failures on their own.

Built during a one-week engineering internship for an AI consulting and training company, the system wasn’t aiming to be the largest possible infrastructure. It aimed to solve the actual delivery problem with an architecture that was fast, dependable, and easy to operate.

Why Sandesh was built this way

Two extremes tend to swallow notifications in modern software engineering: they’re either treated as an afterthought — leading to lost messages and fragile retry logic — or overengineered using massive distributed systems like Apache Kafka for workloads that simply don’t justify the operational overhead.

A different core principle guided Sandesh: Use the simplest architecture that reliably solves the actual problem.

Rather than forcing individual services to reinvent delivery logic, Sandesh acts as a unified traffic controller. It abstracts away channel-specific details, guarantees message prioritization, and handles transient failures gracefully — all while keeping the operational footprint minimal.

Fast when it matters. Reliable when things go wrong. Simple enough to maintain.

The challenge

From the outside, notifications look simple: an application sends a message, a user receives it. In practice, reliable delivery involves much more:

  • Deciding which notification should be sent first.
  • Handling temporary provider or network failures.
  • Retrying messages without creating duplicate delivery loops.
  • Scheduling messages for a future time.
  • Keeping content consistent across channels.
  • Tracking whether delivery succeeded or failed.

What the company needed was a shared notification layer that could handle these responsibilities without adding more infrastructure than the workload required.

One system, three channels

Push notifications, Email, and SMS all share a common delivery workflow in Sandesh.

Applications submit a notification without needing to know how each channel works internally — the platform handles queueing, provider communication, retries, scheduling, and delivery status.

Notification logic stays out of individual products this way, and the organisation gets one reusable foundation for sending messages.

Making urgent messages move first

Not every notification deserves the same urgency. A critical system alert or OTP shouldn’t be delayed behind routine marketing updates just because it entered the system later.

Priority-based queues control processing order in Sandesh, ensuring higher-priority messages get handled first — a practical way to respond quickly to time-sensitive events without requiring a complex distributed messaging platform.

Treating delivery as a process

Sometimes a notification provider fails temporarily, whether from a network issue, rate limit, service interruption, or provider-side error. A failed first attempt is never treated as final in Sandesh.

Where the error is recoverable, the notification returns to the queue according to a controlled retry policy — improving resilience while avoiding the risks of uncontrolled retries, repeated failures, and unnecessary pressure on external providers.

The delivery lifecycle is:

Created → Queued → Attempted → Delivered or Retried → Completed

Scheduling messages for later

Immediate delivery isn’t always what a message needs — sometimes it needs to wait.

Scheduled notifications let an application specify when a message should become eligible for delivery, making the same platform useful for reminders, planned updates, follow-ups, and time-based communication without relying on external cron jobs in product code.

Reusable notification templates

Brand and layout consistency get harder to maintain when every notification is written from scratch.

Reusable templates with dynamic variable insertion solve that in Sandesh, letting applications use standard message structures while still personalizing the content for each recipient.

Choosing the right amount of infrastructure

One of the most important decisions in the project was choosing not to introduce Kafka.

Kafka is powerful, but the organisation’s notification volume and operational requirements didn’t justify the additional complexity of running a heavyweight distributed event-streaming cluster.

Instead, a lightweight priority-queue architecture designed around the actual workload does the job — ordering, retries, scheduling, and failure handling, without an infrastructure burden the business didn’t need.

Performance under measured conditions

Real delivery requirements were the benchmark. Under measured operating conditions, Sandesh achieved:

Metric Measured Outcome
Push Notification Latency Sub-300 ms at 95% confidence (p95)
Email Delivery Reliability ~98% successful delivery rate
Supported Channels 3 (Push, Email, SMS)

Measured through internal load testing against the company’s expected notification volume, tracking p95 latency and delivery success rate across repeated test runs.

A deliberately simple architecture, these results showed, could still provide responsive and dependable delivery across the required channels.

From request to delivery

The complete workflow looks like this:

Application request → Template rendering → Priority queue → Scheduled processing → Provider delivery → Retry or completion

Responsibilities divide cleanly across the architecture:

  • Node.js & Express: Coordinates the core delivery workflow, priority queue logic, and REST APIs.
  • Firebase Cloud Messaging (FCM): Handles push notification delivery to mobile and web clients.
  • Nodemailer: Manages SMTP integrations for transactional emails.
  • MongoDB: Persists message logs, delivery statuses, scheduled tasks, and template definitions.
  • React Frontend: Provides an intuitive dashboard for monitoring queues, inspecting delivery logs, and managing templates.

Outcome

Within one week, a reusable notification foundation for delivering push notifications, email, and SMS is what Sandesh became.

One place to manage notification priorities, retries, schedules, templates, and delivery outcomes — that’s what the company got. Just as importantly, overengineering never crept in: the system met real requirements without unnecessary operational complexity.

Project highlights

  • Built a multi-channel notification platform in one week during an engineering internship.
  • Supported push notifications, email, and SMS in a unified pipeline.
  • Implemented priority-based queues for time-sensitive alerts.
  • Added controlled retries for recoverable delivery failures.
  • Supported native scheduled notification delivery.
  • Created reusable templates with dynamic content injection.
  • Achieved sub-300 ms push delivery at 95% confidence under test conditions.
  • Reached approximately 98% email delivery reliability.
  • Adopted a lightweight queue-based architecture over heavy distributed streaming infrastructure.
  • Integrated Firebase for push and MongoDB for state persistence.
  • Built a React-based management interface for monitoring delivery health.