DEV Community: Nikita Navral

Choosing The Right Message Queue Technology For Your Notification System

Nikita Navral — Fri, 16 Oct 2026 10:57:47 +0000

Your notification system works great at 100 messages a minute. Then your app goes viral, a flash sale hits, and suddenly your OTPs are stuck behind 2 million promotional pushes.

Sooner or later, every notification system needs a message queue. The hard part is picking one. Kafka, RabbitMQ, SQS, Pub/Sub and Kinesis all "move messages," but they behave very differently when you need ordering, retries, replays or priorities.

This guide walks through the factors that matter for notifications, compares the five most common options, and ends with a checklist you can use to decide.

First, what do notifications need from a queue?

Forget feature lists for a second. Here's what actually matters, with a real scenario for each.

Scalability

Your sports app sends a push whenever a team scores. Traffic is quiet until a derby match, then every user gets a notification within seconds. You need a queue that scales out without redesign.

Message retention

You send transaction alerts in real time. One night your consumer crashes for 30 minutes. If the queue discards messages that aren't consumed, those users never hear about their money moving.

With retention, messages wait in the queue (for an hour, a day, longer) and are processed when the consumer comes back.

Low latency

A fraud team needs to be alerted the moment a suspicious transaction appears. Delay matters here.

A caveat: Redis Pub/Sub is often cited for this, but it's fire-and-forget. If no subscriber is listening, the message is gone. For anything you can't afford to lose, use Redis Streams or a durable broker.

High throughput

A food delivery app sends status updates ("being prepared", "on its way") for every order. Volume is high, and many consumers need to process it in parallel. This is where Kafka and Kinesis shine.

Message ordering

A trading platform sends market alerts. If "price dropped" arrives after "price recovered," users act on stale information. You need ordering guarantees, at least per user or per entity.

Prioritization

A hospital monitoring system alerts nurses when a patient's heart rate crosses a threshold. That alert can't wait behind a batch of routine reports.

One thing to know: most queues don't have native priority. The usual pattern is separate queues or topics per priority:

TOPICS = {
    "critical": "notif.critical",   # OTP, security, health alerts
    "high":     "notif.high",       # transactional
    "low":      "notif.low",        # promos, digests
}

producer.send(
    TOPICS[msg.priority],
    key=msg.user_id.encode(),   # same user -> same partition -> ordered
    value=payload,
)

Each topic gets its own consumers and throughput limits, so a promo blast can't starve your OTPs. (RabbitMQ is the exception, with native priority queues.)

Dead letter queues (DLQs)

An e-commerce site sends order confirmations. Some email addresses are invalid and fail every time. Without a DLQ, those messages are retried forever or block the line. With a DLQ, failures move aside where you can inspect them and fix the cause.

{
  "RedrivePolicy": {
    "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789012:notif-dlq",
    "maxReceiveCount": 5
  }
}

That's an SQS redrive policy: after 5 failed receives, the message goes to the DLQ.

The five contenders, side by side

	RabbitMQ	Kafka	AWS SQS	Google Pub/Sub	AWS Kinesis
Model	Broker with exchanges and queues (AMQP)	Distributed log, consumer groups	Queue (pull)	Topics and subscriptions (push or pull)	Streams split into shards
Ordering	FIFO per queue	Per partition	FIFO queues, per message group	Per ordering key (opt-in)	Per shard / partition key
Latency	Very low	Low	Low	Low	Low
Throughput	Moderate to high	Very high	Very high	High	High (shard-bound)
Retention / replay	Until acked (Streams plugin adds replay)	Configurable, replayable	Up to 14 days, no replay	Configurable, can seek back	24h up to 365 days, replayable
Native priority	Yes	No (use separate topics)	No (use separate queues)	No (use separate topics)	No (use separate streams)
Dead letter queue	Dead-letter exchanges	DIY (a DLQ topic)	Native	Native	No native DLQ (handle in the consumer)
Ops burden	Moderate (self-host or managed)	Heavy if self-hosted, managed options exist	Fully managed	Fully managed	Fully managed
Pricing	Infra cost if self-hosted	Infra cost if self-hosted	Pay per request	Pay per volume	Pay per shard / volume
Access control	vhosts and permissions	ACLs	IAM	IAM	IAM

Limits like max message size change over time, so check each provider's docs before you design around them.

Which one should you pick?

Here are three common situations.

🚀 Startup with low-volume transactional notifications → RabbitMQ (or SQS)

Easy to set up, simple to reason about, and flexible routing. It has native priority queues and dead-letter exchanges, so you get a lot of notification-friendly features without much ceremony. If you're all-in on AWS and want zero ops, SQS is a strong alternative.

📈 Mid-sized company, high volume, low latency → Kafka

Distributed, high throughput, and great for fan-out: one event can feed email, push and analytics consumers at once. Replication and replay are strong, and you can reprocess history when something goes wrong. The trade-off is operational complexity, so consider a managed offering.

🏢 Enterprise on AWS with many microservices → Kinesis (plus SNS/SQS where it fits)

Fully managed, integrates natively with Lambda and the rest of AWS, and handles large volumes. Kinesis is a streaming service rather than a classic queue, so many teams pair it with SQS or SNS for simple fan-out and retry patterns.

At-least-once delivery means you need idempotency

Almost every queue above delivers messages at least once. Retries and rebalances can deliver the same message twice, and a user getting the same "payment received" push twice is a bug.

def handle(msg):
    if already_processed(msg.id):      # e.g. Redis SETNX or DB unique key
        return
    send_notification(msg)
    mark_processed(msg.id)

Whichever queue you pick, build this in from day one.

Latency vs throughput: you can't max both

Optimizing for one tends to cost you the other.

Low latency needs fast ingest and delivery, which uses more CPU, memory and network per message.
High throughput relies on batching and parallelism, which can add a little delay per message.

RabbitMQ leans toward low-latency, real-time delivery. Kafka leans toward high-throughput streaming, but it's tunable (settings like batch size and linger time let you trade one for the other). Even then, hardware and architecture set the limits.

A practical rule: use low-latency settings for your critical queue (OTPs, alerts), and throughput-optimized settings for the low-priority bulk queue.

A checklist for deciding

Run through these before you commit.

Define your numbers. Message volume, latency target, reliability needs.
Pick your trade-off. Latency or throughput first?
Plan for growth. Can it scale horizontally as your user base grows?
Check ecosystem fit. Your languages, frameworks and existing cloud provider.
Count the operational cost. Setup complexity, monitoring, and what your team already knows.
Check security. Durability, access control and encryption in transit.
Budget it. Infrastructure, managed service fees and maintenance time.
Prototype and load-test. Don't trust benchmarks, including the ones in this post. Test with your own traffic.

Running multi-cloud or hybrid?

A few things to watch for:

Multiple queue technologies. Different components may use different brokers. Make sure your team can operate all of them.
Standard protocols. Prefer widely supported protocols like AMQP or MQTT where you can, and keep message formats consistent to avoid fragmentation.
Complexity vs flexibility. Cross-environment connectivity adds moving parts. Make sure the flexibility is worth it.

Wrapping up

There's no single best message queue, only the best fit for your volume, latency needs, team and cloud. Balance performance, reliability, ease of use and ecosystem, and revisit the decision as your notification system grows.

And if you'd rather not build and operate this whole layer yourself (queues, priorities, retries, fallbacks), that's what we built SuprSend for. Full disclosure: we work on it, so take that into account.

Your turn: which queue are you running notifications on today, and would you pick it again? Tell us in the comments. Horror stories welcome.

Introducing SuprSend Agent

Nikita Navral — Thu, 15 Oct 2026 07:54:36 +0000

Quick intro: we're the team behind SuprSend, a notification infrastructure platform. Today we're launching SuprSend Agent, and we wanted to share what we built, how it's wired, and the guardrails we put around it.

The 30-second version

SuprSend Agent is an AI agent that lives inside the SuprSend dashboard. You describe what you need in plain English, and it builds, configures and debugs your notification setup for you.

It's connected to:

the full SuprSend API surface
the product documentation
agent skills
domain knowledge about how notifications actually work

So it doesn't just fire off API calls. It understands your use case, picks the right tools, applies the correct configuration, and tests the result.

Try it: SuprSend Agent | Docs: read the docs

Why we built it

Notifications are deceptively deep. One message passes through several layers of logic: who gets it, on which channel, at what time, with what content, and what happens if the user does (or doesn't) act. Every layer has to be configured, tested and iterated.

That depth is what lets a platform handle real-world use cases. It's also why it takes days to build a mental model before you configure anything.

The agent shifts where that effort goes:

New users skip the upfront learning curve. Ask the agent how things work, and let it set up your first workflows.
Existing users skip the click-through. No more hopping between screens to change a vendor, check an object or tweak a template.

What you can do with it

1. Ask anything (without opening another tab)

Data modeling, how a feature works, what an error means, best practices, how to approach an integration. It answers from the docs.

"How do preferences cascade from defaults to tenants to end users?"

2. Manage your assets from a chat

The agent can create, retrieve, update and commit across tenants, objects, preferences, vendors, translations and schemas.

"Update the SMS vendor for tenant cypher and show me the current preference categories."

3. Design and test a notification from one prompt

This is the one we're most excited about. Normally you decide everything yourself: flow structure, timing, branching, channels, and how the content should read on each one.

Now a prompt like this is enough:

"Set up a trial expiry reminder for new users."

The agent will:

Map out the workflow nodes
Set the time delays
Add the branching logic
Pick the right channels
Design and personalize the templates with variables
Test the result across every channel

You describe the outcome. It handles the build.

4. Ask your analytics anything

A fixed dashboard only answers the questions it was built for. The agent reads your notification data through a semantic layer over the data lake, so you can ask things like:

Which notifications performed worst in the last 30 days?
What's the best performing template this week?
How do channels compare across segments and tenants?
How many workflows are active?

"Show me delivery and open rates for the weekly-digest workflow, split by tenant, for the last 30 days."

It returns the answer, can visualize it as a chart, and can post it straight to Slack.

5. Debug "why didn't they get it?"

We all know this one. A notification doesn't arrive, and the cause could be a channel issue, a preference opt-out, a tenant override or a vendor failure. Finding it means digging through logs and screens.

"User john@cypher.com says he's not getting emails. What's wrong?"

The agent traces the delivery, finds what stopped it, explains the cause and suggests a fix.

"Cool, but is it safe on a live workspace?"

Fair question, and honestly the one we spent the most time on. The agent acts on real organizational data, so safety is built into every step:

Guardrail	What it means
Workspace-scoped access	Every session is limited to one workspace. A conversation in one can't read or change data in another.
Service token auth	Each session uses a workspace-scoped JWT that expires and auto-refreshes, so access is short-lived by default.
Permission before changes	The agent asks for confirmation before any edit. Updates read the resource's current state first, so nothing is silently overwritten.
No destructive deletes	Deletes aren't exposed to the agent at all. Only low-risk, reversible operations (like removing a user from a list) are allowed.
Validated, not guessed	It runs on validated SuprSend schemas and product knowledge, so it uses correct parameters instead of guessing.

Who is it for?

Developers, product managers, marketing, customer success and ops teams. Basically anyone who manages notifications but doesn't want to write integration code for every change. Work that used to wait on engineering can now happen in a conversation.

A bigger shift

This launch is part of a larger direction: SuprSend is becoming AI-first notification infrastructure, where you operate the platform by describing what you need instead of learning every knob and switch.

Try it and tell us what you think

Start with a first prompt in the dashboard: Try SuprSend Agent

We'd love to hear from you in the comments:

What's the first thing you'd ask the agent to build?
What guardrails would you want on an AI agent that touches production config?
What's the most painful notification bug you've ever had to debug?

We read every reply. 👇

A complete guide on Notification Service for Modern Applications in 2026

Nikita Navral — Wed, 14 Oct 2026 10:53:02 +0000

Most notification services start as a single function:

def notify(user, message):
    email_client.send(user.email, message)

It works for a while. Then product asks for push, then SMS, then an in-app inbox, then "can users pick what they get?" Before long, this one function has become a distributed system.

This post breaks down what a production notification service contains, split into the functional parts users and PMs see, and the non-functional parts that keep it alive at 3 a.m. At the end, there's a framework for deciding whether to build or buy.

The big picture

Your app --> Notification API --> Preference check --> Template render
                                        |
                              Priority queues (critical / high / low)
                                        |
                              Channel workers (email, SMS, push, inbox...)
                                        |
                              Vendor adapters --> Webhooks --> Analytics

Each box hides real engineering work. Let's go through them.

Part 1: Functional components

1. Delivery channels and vendor integrations

Users live on different channels: email, SMS, push, in-app inbox, WhatsApp, Slack or Teams, even automated calls. To maximize engagement you'll want several of them.

Every channel means picking a vendor, learning its API, testing quality of service, monitoring it, and planning a fallback. A common way to keep this manageable is an adapter layer:

class ChannelAdapter:
    def send(self, payload) -> DeliveryResult: ...

class SendgridAdapter(ChannelAdapter): ...
class TwilioAdapter(ChannelAdapter): ...
class FcmAdapter(ChannelAdapter): ...

Your core logic talks to one interface, and vendor quirks stay at the edges.

2. Templating engine

Templates quietly become the biggest ownership burden. They need constant changes for copy, personalization, branding, dynamic variables, conditional logic, multi-lingual support, and correct rendering across devices.

Each channel also has different strengths:

Email: long, detailed content
SMS: short and attention-grabbing
Push: rich media and action buttons

If every copy change needs a deploy, your engineers become a bottleneck. The fix is a visual editor so PMs and marketers can build and test without a pull request.

3. User preferences

Marketing emails get a simple unsubscribe link. Product notifications are trickier, because users want some of them (security alerts) and not others (weekly tips).

A decent preference system lets users control:

Type: which categories they get
Channel: where they get them
Frequency: instant, hourly, daily or weekly digest
Timing: quiet hours

def should_send(user, notification):
    prefs = get_preferences(user.id)
    if notification.category not in prefs.enabled_categories:
        return False
    if in_quiet_hours(user, prefs) and not notification.is_critical:
        return reschedule(notification, prefs.quiet_hours_end)
    return True

Without this, users do the only thing they can: block everything.

4. Batching and digests

Say your product has comments. If 20 people reply to a thread, you don't want 20 notifications. You want one: "20 new comments."

Batching: define a window, collect events inside it, then send one combined message.
Digests: send a summary at a cadence the user chooses, such as hourly, daily or weekly.

Depending on the notification type, you may need both.

5. Multi-tenancy

If your product serves other businesses and sends notifications to their users, you need tenant-level isolation and customization: their branding, their sending domain, their channels, their preference rules.

Example: a SaaS tool sending invoices on behalf of customers. The end user doesn't know your brand, so the email must carry your customer's logo, content and sender identity, all running on shared infrastructure.

6. Analytics

PMs need delivery, open and click data to improve notifications. But every channel and vendor reports differently, and some metrics don't exist (you can't track opens on SMS).

That means you need a normalized event model, so cross-channel analysis is possible:

{
  "event": "delivered",
  "channel": "email",
  "notification_id": "n_123",
  "user_id": "u_456",
  "timestamp": "2026-10-14T10:32:00Z"
}

Map vendor webhooks into this shape and you can compare channels apples to apples.

Part 2: Non-functional components

This is the stuff nobody sees until it breaks.

1. Scalability and load balancing

Notification traffic spikes unexpectedly: a flash sale, a viral feature, an incident. Design for bursts, and balance load across servers and regions.

2. Fault tolerance and retries

Downtime isn't acceptable for OTPs or compliance messages. You need redundancy, state management, fallback vendors, and rate-limit-aware throttling per channel.

One subtle point: not every failure deserves a retry. An expired push token is dead, and retrying it just wastes resources.

RETRYABLE = {"timeout", "rate_limited", "vendor_5xx"}
PERMANENT = {"invalid_token", "unsubscribed", "bounced"}

def handle_failure(msg, reason):
    if reason in RETRYABLE:
        retry_with_backoff(msg)
    elif reason in PERMANENT:
        mark_channel_inactive(msg.user_id, msg.channel)

Understanding why something failed matters as much as retrying it.

3. High deliverability

Reaching the user involves several things at once: multiple channels, reliable vendors, cleaning inactive contacts, and managing bounces.

4. Low latency

People expect notifications fast. Cut network round trips, optimize database queries, and shorten delivery paths. It's ongoing work, because performance degrades as you scale.

5. Observability

You need detailed logging, error tracking and performance monitoring so you can diagnose failures quickly and answer compliance questions. If you can't answer "what happened to this user's notification?", debugging becomes guesswork.

6. Message queue prioritization

This one saves a lot of pain. An OTP and a weekly newsletter shouldn't share a queue. If bulk sends clog the pipeline, login codes get delayed and drop-off rises.

Use separate queues with their own throughput limits:

QUEUES = {
    "critical": {"workers": 20, "rate": "unlimited"},   # OTP, security
    "high":     {"workers": 10, "rate": "1000/s"},      # transactional
    "low":      {"workers": 3,  "rate": "200/s"},       # promos, digests
}

This protects critical messages without over-provisioning for everything.

To build or not to build?

Here's a quick framework.

Build in-house when:

Your needs are simple. Few notification types, low volume, rare changes, a single channel. Direct vendor integration or a lightweight internal service will do.
You need heavy customization. Your use case is unusual enough that third-party platforms can't support it (like a chatbot over SMS).
Notifications are your product. If you're something like WhatsApp, owning it makes sense.

Consider alternatives when:

Resources are limited. Building and maintaining this takes real engineering capacity.
Time to market matters. A third-party service can get you live far faster.
You need complex features. Workflows, white-labeling, preferences, personalization, batching and cross-channel logic come ready-made on established platforms.
You want to focus on your core product. Getting notifications right takes experimentation, channel expertise, scaling work and observability, which pulls attention from what makes your product special.

This is the layer we built SuprSend to handle, so teams can skip the plumbing. Full disclosure: we work on SuprSend, so weigh that accordingly. The checklist above holds whichever way you go.

Wrapping up

A good notification service balances two sides. The functional side gives product teams control over templates, preferences and analytics. The non-functional side gives everyone reliability, speed and visibility. Skipping either one hurts.

Whichever path you choose, the goal is the same: a smooth, meaningful experience that keeps users connected.

Over to you: did you build your notification system in-house or use a platform? What's the one component you wish you'd planned for earlier? Tell us in the comments.

Notifications Are Not Just an API Call: 11 Reasons They Quietly Eat Your Sprint

Nikita Navral — Tue, 13 Oct 2026 13:24:26 +0000

Every product team starts the same way: "We just need to send an email when someone signs up." One SDK, one template, done by Friday.

Six months later you have four channels, three vendors, a pile of cron jobs, and a PM asking whether the payment reminder copy can be changed without a deploy.

Notifications look trivial and behave like infrastructure. They're how your product talks to users: alerts, reminders, recommendations, launches, even user-to-user messages. Send too little and the experience breaks. Send too much and people unsubscribe. Here are the 11 places where it gets hard.

1. Trivial tasks that keep landing on engineers

Notification logic is rarely hard. What's hard is iteration. Getting the content, trigger and timing right takes many tries, and PMs want to move fast. But when templates and triggers live in code, every tweak joins the sprint queue. Adding a new channel to an existing notification multiplies the work again.

The fix: let non-engineers edit content and logic without a deploy.

2. Nobody knows what's actually live

Before building a new notification, you need to know what already exists. Answering that means digging through the code or trusting a shared doc that went stale weeks ago. With several PMs involved, legacy notifications keep running because nobody wants to audit them. Cleanup becomes a once-or-twice-a-year project.

3. Testing is a coordination problem

Testing notifications isn't technically complex, but it eats time. Test sends often go to one shared device or account that not everyone can access. Scheduled notifications usually need a developer to trigger them manually whenever QA or a PM wants to check them. That's a lot of context switching for something that should be self-serve.

4. Scaling exposes the cracks

As volume grows, delivery reliability becomes your problem.

No priority separation. If a promotional blast clogs the queue, your OTP sits behind it. Scaling everything up to compensate gets expensive. What you want is immediate delivery for transactional messages and staggered delivery for promotional ones:

# Pseudocode: route by priority so promos never block transactional
queue = "transactional" if msg.category in ("otp", "payment", "security") else "promotional"
publish(queue, msg)

No fallback or retries. If the provider API is down, queued messages are lost, and so is important communication. You need retries and a fallback path.

No failure alerts. Many teams only learn about failed deliveries when the business team or a customer complains. In the worst case, they never find out. Treat delivery failures like server downtime and alert on them.

Stale deliveries. A delayed message that arrives two weeks later, like a "payment debited" notice, is worse than no message. Put an expiry on time-sensitive notifications:

# Drop the message if it's too old to be useful
if now() - msg.created_at > msg.ttl:
    mark_expired(msg)
    return

It sounds like a rare edge case, but it leaves a bad impression when it happens.

5. Analytics are scattered

Each vendor gives you its own dashboard, which makes it hard to compare delivery and click rates across channels. User-level analytics are even rarer. How many messages did one user get this week? Did several fire at once? What does the overall experience feel like from their side? Without that view, users end up either under-engaged or bombarded.

6. Multi-channel is a tightrope

Reaching users on every channel raises conversion, but it also raises unsubscribes. It's also costly to send the same message on three channels when the user saw it on the first.

A smarter approach staggers delivery across channels based on past behavior and message type:

Push -> wait 30 min -> not seen? -> Email -> wait 24h -> not seen? -> SMS

That saves money and avoids spamming people.

7. Sending to dead channels

People change numbers and leave companies. Messages to inactive contacts cost money, and high email bounce rates damage your domain reputation, which can push future emails into spam. Most tools report a bounce only after you've sent. It's far better to filter out inactive channels in advance and keep your contact data clean.

8. Multi-lingual support

Expanding into non-English markets means storing each user's language preference and maintaining a template per language, per channel. The engineering effort grows quickly, even though the logic stays the same.

9. Users want a say

Letting users choose what they get notified about is good engagement strategy. Without granular preferences, many users take the only option available and unsubscribe from everything, which hurts engagement and sales. Quora is a good example: users can opt out of specific types of emails without leaving entirely.

10. One-size-fits-all frequency

Engagement notifications usually run on a fixed schedule, because custom frequency per user isn't feasible by hand. The result is endless reminders for users who aren't interested, while engaged users could be getting more.

A smarter system adapts to behavior: send more when users respond, back off when they go quiet, and try a different way to re-engage. That requires per-user data processing feeding back into the delivery pipeline, which most startups can't justify building. So they settle for light personalization and a frequency cap. It works, but it leaves engagement on the table.

11. Vendor lock-in and reliability

No vendor guarantees 100% uptime. For time-sensitive messages like OTPs, you need a fallback vendor. But every vendor has its own API and integration rules, so each one costs real engineering time:

for vendor in ["vendor_a", "vendor_b"]:
    try:
        return send(vendor, msg)
    except VendorError:
        continue
raise DeliveryFailed(msg.id)

Looks simple, until you maintain two or three vendors' payload formats, webhooks and error codes. Most teams stay with one vendor per channel until an outage forces the issue, or pick a multi-channel vendor that may not be the cheapest option.

Wrapping up

None of these problems is impossible alone. Together, they turn "just send a notification" into a standing drain on your team's time.

That's the problem we're building SuprSend to solve, so engineering teams can stop reinventing notification infrastructure and focus on their core product.

Now I'm curious: how does your team handle notifications today? Home-grown service, a single vendor, or something else? What's been the biggest pain point? Let us know in the comments.