Notifications: alerts, status changes, daily digests, sub-second time pressure.
High-volume notifications sit between transactional and marketing in volume but are time-sensitive like transactional. Examples: SaaS product notifications (someone mentioned you, your build failed, your invoice is due), financial alerts (balance threshold, fraud detection, security advisory), operational pages (your incident is escalating, your deployment finished, your monitoring alert fired). The volume is high — sometimes millions per day across a customer base — but each individual message needs to land in seconds because there is a recipient waiting for it. The infrastructure problem is sustaining peak send rate without sacrificing per-message latency.
Why do most providers choke on the burst rather than the steady state?
A notification burst is bimodal: 95% of the time you are sending at 1-5K/hour, then a triggering event — a deployment, a market move, a security incident at one of your customers — causes you to send 500K in 15 minutes. Most providers handle the steady state fine and choke on the burst. The choke takes different forms: SES rate-limits and queues internally with a multi-minute delay; SendGrid Pro throttles to protect shared infrastructure; managed services with hourly capacity caps reject submissions until the rate window resets. We design for the burst case specifically: 2× headroom on every PoP, burst-absorption capacity pre-provisioned, separate dispatch queues for time-sensitive vs background traffic.
What makes notifications different from marketing or transactional?
Notifications differ from marketing because the recipient is genuinely waiting (engagement is not optional, it is the entire point). They differ from transactional because the volume per event can be 100-1000× the steady state. They share with transactional the requirement for low latency, and share with marketing the requirement for high throughput. Most senders in this category run a hybrid setup — a small transactional pool for OTPs and password resets, a notification pool that scales for bursts, and sometimes a separate marketing pool. We support all three on the same account with separate IP pools, separate stats, separate webhook routing.
Is a notification transactional or marketing for compliance?
The word "notification" hides a consent question, and the answer decides which rules apply. A genuine operational alert — your build failed, your invoice is past due, a login from a new device — is transactional, and it reaches the recipient without marketing consent because the recipient asked for the underlying service. A "notification" that promotes a feature, invites you to a webinar, or nudges an upsell is marketing in substance no matter which system sends it, and it needs consent and a working one-click unsubscribe under the Gmail and Yahoo sender rules and under GDPR. The temptation is to route the promotional kind through the notification pipeline to skip the unsubscribe flow, and it backfires every time: a recipient who cannot opt out of something plainly promotional reaches for the spam button instead, and the complaint lands on the pool that was supposed to stay clean for the alerts that matter. We separate the streams at the pool and policy level — true transactional and operational notifications on a pool with no marketing mixed in, anything carrying a promotional element on a pool that publishes List-Unsubscribe and honors preferences. The classification is not bureaucracy; it is what keeps the reputation of the genuine alerts intact.
We are the delivery layer under an orchestrator, not the orchestrator.
A growing share of notification systems run an orchestration layer on top — Courier and Knock are the common ones — that routes a single notification across email, SMS, push, in-app, and Slack according to user preference and fallback rules like "try in-app first, fall back to email if unseen within ten minutes, escalate to SMS for a high-priority alert." We are not that layer, and for a product that needs genuine multi-channel routing with a preference center we will name it rather than pretend an email API covers the job. What we are is the email leg those orchestrators route into, chosen for EU residency and the pre-provisioned burst capacity the category demands. The topology is common among our customers: an orchestrator, or a self-hosted equivalent such as Notifuse, sitting on top, with us as the email provider underneath. The integration is plain — the orchestrator calls our send endpoint with the rendered message, a priority flag, and a tenant tag, we return a message ID, and our webhooks feed delivery state back so the orchestrator can decide whether to escalate to another channel. Being underneath the orchestration layer changes none of the burst handling, the per-tenant pacing, or the residency guarantees, which hold whether the call comes from your application directly or from a Knock workflow upstream.
Who owns notification sprawl across teams?
Notification volume is rarely owned by one team. Marketing sends campaigns, product sends lifecycle and feature alerts, customer success sends check-ins, sales sends follow-ups, and engineering sends the transactional traffic, and no single team sees the total a given recipient receives across all of it. The audit that counts messages per user per week tends to shock the people who run it, because the aggregate is always higher than any one team assumed. That matters for deliverability, because mailbox providers judge the cumulative experience: a recipient buried under touches from five teams complains, and the complaint does not care which team sent the message that broke the patience. We make the total picture visible — per-tenant and per-stream volume through the X-OSD tagging headers, queryable so you can see how many touches a recipient is getting across streams rather than within one. We support cross-stream suppression as well, so a complaint can suppress every non-transactional message to that recipient for a cooling-off window while the genuine alerts still get through. Deliverability in 2026 is shared ownership across marketing, product, engineering, and legal, and the only way to govern it is to see it in one place.
The burst is a per-provider problem, and the providers do not burst the same way.
A notification burst is not one delivery problem; it is a different problem at each receiving provider, firing at once. A fanout of fifty thousand alerts in fifteen minutes is comfortable for Gmail, which tolerates a high rate from a trusted sender, while Yahoo defers aggressively and asks you to slow down, and Microsoft applies a constraint most senders forget until it bites: the tenant external-recipient rate limit caps a whole Microsoft 365 tenant at five thousand external recipients a day. When a fanout concentrates inside one large customer — a status-page incident alerting every user at a single enterprise — those few thousand messages can exhaust that tenant's daily allowance and stall the rest of its mail, including mail that has nothing to do with you. Our scheduler smooths the rate per recipient domain and, for Microsoft, per tenant, so no single provider and no single customer tenant sees the whole burst at once. The steady-state send rate is never the hard part; the hard part is shaping a spike so that the providers most likely to throttle never see a spike at all.
Why do steady-state latency benchmarks mislead for this category?
A latency number quoted without the load it was measured under is close to meaningless for this category. Most providers publish a median measured at steady state, and the number that decides whether a fraud alert or an outage page lands in time is the p99 latency during the burst, when queues are deepest. The difference usually comes down to how capacity is added. A platform that autoscales into a burst pays a cold-start penalty measured in minutes precisely when a time-sensitive alert cannot absorb it, so the scaling event itself sits in the critical path and the steady-state number stops describing reality. We pre-provision burst headroom on every point of presence rather than scaling on demand, which means the capacity is already warm when the spike arrives and there is no scaling event between submission and dispatch. The result is a p99 submission latency held around 180 milliseconds and dispatch within minutes even mid-burst, not because the steady-state pipe is fast, but because the burst capacity was paid for before the burst rather than summoned during it.
When is email the wrong channel for an alert?
Email is a strong default for notifications, and it is the wrong primary channel for an alert measured in seconds. A pager escalation, a fraud block, an outage that is actively worsening — these need a channel that delivers in seconds with a read receipt, and email delivery into a corporate mailbox can take minutes through a tenant gateway no matter how clean the sender is. For those, SMS, push, or a Slack message is the right front line, with email as the durable record and the fallback. We are an email provider, so the real-time critical-alert leg is not ours to run, and we will name the orchestrator and the SMS or push provider for it rather than imply that an email API solves a latency requirement that belongs to a different medium. Where email is the right tool is the large surface of notifications that do not turn on a single second: the daily digest, the build-finished note, the invoice reminder, the security advisory that needs to arrive reliably and become part of the record. Drawing that line honestly tends to earn more trust than claiming the inbox answers every alert, because the buyer has usually already watched an email-only alerting setup miss a deadline that mattered.
Batching low-priority notifications into a digest protects deliverability.
Not every notification needs to be its own email. Bundling low-priority, non-time-critical notifications into a scheduled digest cuts the per-recipient send frequency, and frequency is one of the signals that drives complaints and unsubscribes. A user who receives twenty separate "someone commented" emails in a day starts marking them as spam; the same twenty arriving as one daily digest stay welcome. The deliverability win is direct. Fewer sends to the same recipient means a lower chance of fatigue-driven complaints and a higher average engagement per message, which is exactly the ratio mailbox providers reward when they decide placement. We support scheduled digest windows and per-recipient frequency caps, so the application can mark a notification as digest-eligible and let the platform bundle it, while a genuinely time-sensitive alert bypasses the digest and dispatches immediately. The design question for each notification type is whether the recipient needs it in seconds or needs it in a daily summary, and routing the second kind into a digest protects the reputation the first kind depends on. The teams that turn every product event into its own email are the ones whose engagement quietly erodes and whose complaint rate creeps toward the filtering threshold; the teams that batch aggressively keep the inbox relationship healthy and the genuine alerts trusted.