¿Qué son las notificaciones de alto volumen?
Las notificaciones de alto volumen se sitúan entre el transaccional y el marketing en términos de volumen, pero comparten con el transaccional la sensibilidad al tiempo. Los ejemplos típicos: notificaciones de producto SaaS (alguien te mencionó, tu build falló, tu factura vence en 3 días), alertas financieras (umbral de saldo, detección de fraude, advertencia de seguridad sobre login desde IP desconocida), páginas operativas (tu incidente está escalando, tu deploy terminó, tu monitoreo disparó alerta), notificaciones de marketplace (recibiste un mensaje, alguien compró tu producto, alguien dejó review). El volumen es alto —a veces millones diarios distribuidos en una base de clientes— pero cada mensaje individual tiene que aterrizar en segundos porque hay un destinatario esperando. El problema arquitectónico es sostener tasa pico de envío sin sacrificar latencia por mensaje, y eso requiere disciplina específica que muchos proveedores no tienen porque diseñaron para o transaccional puro o marketing puro.
¿Por qué el burst bimodal rompe a la mayoría de los proveedores?
Un burst de notificaciones es bimodal por naturaleza: el 95% del tiempo estás enviando a 1-5K/hora, y entonces un evento desencadenante —un deploy, un movimiento de mercado, un incidente de seguridad en uno de tus clientes, una caída de servicio de un proveedor que afecta a varios— provoca que envíes 500K mensajes en 15 minutos. La mayoría de los proveedores manejan el steady state correctamente y se atragantan en el burst. El atraganto adopta formas distintas: SES limita rate y encola internamente con retraso multi-minuto que es invisible al cliente hasta que aparece; SendGrid Pro throttlea para proteger su infraestructura compartida; los servicios gestionados con caps de capacidad horarios rechazan submissions hasta que la ventana del rate se resetea. Diseñamos específicamente para el caso de burst: 2× headroom permanente en cada PoP, capacidad de burst-absorption pre-provisionada, colas de despacho separadas para tráfico time-sensitive vs background. La idea: no quieres descubrir que tu proveedor se atraganta el día que tu plataforma tiene un incidente.
Qué hace a esta categoría distinta del marketing y del transaccional.
Las notificaciones difieren del marketing porque el destinatario está realmente esperando (engagement no es opcional, es el propósito completo del mensaje). Difieren del transaccional porque el volumen por evento puede ser 100-1000× el steady state, lo que hace que el dimensionamiento estable no baste. Comparten con el transaccional el requisito de baja latencia, y comparten con el marketing el requisito de alto throughput. La mayoría de los senders en esta categoría operan un setup híbrido: un pool transaccional pequeño para OTP y password resets, un pool de notificaciones que escala para bursts, y a veces un pool separado de marketing. Soportamos los tres en la misma cuenta con pools de IP separados, estadísticas separadas, webhooks separados routables a endpoints distintos según el flujo. La separación importa porque un complaint spike en marketing no debe degradar la entrega de tus alertas de seguridad.
¿Por qué los webhooks fiables importan tanto en notifications?
En notifications, los webhooks no son nice-to-have: son el contrato entre tu plataforma y la nuestra. Cada vez que enviamos un evento (queued, delivered, bounced, deferred, complained, replied) entregamos el webhook firmado con HMAC-SHA256 sobre el body completo, con timestamp Unix en epoch segundos dentro de la firma para protección anti-replay con ventana 5 minutos. La cabecera de firma es X-OSD-Signature con formato v1=hex_hash. La idempotencia es responsabilidad del receiver pero hacemos lo que podemos para facilitar: cada evento lleva un message_id único, así que tu endpoint puede usarlo como idempotency key y descartar duplicados durante una ventana razonable (recomendamos 7 días, que coincide con nuestro retention). El esquema CloudEvents v1.0 hace nuestro payload interoperable con AWS EventBridge, Google Eventarc, Knative y Argo Events sin parsing custom. Si tu endpoint cae, reintentamos durante 30 minutos con backoff exponencial (5s, 25s, 125s, 625s, 3125s); pasada esa ventana los eventos van al buffer de replay de 7 días donde quedan disponibles para drenaje cronológico cuando tu endpoint vuelva. El replay manual desde panel está disponible para Performance y Enterprise.
Cross-PoP failover y por qué Performance vale la pena para notifications.
Los clientes Performance y Enterprise tienen routing multi-PoP: si un PoP pierde transit (porque uno de los IXs cae, porque hay un BGP problem que un upstream tarda en resolver, porque un datacenter tiene incidente con su transit principal), el tráfico se desvía al PoP alterno en menos de 30 segundos. Los planes Starter y Standard son single-PoP y verían la interrupción durante toda la duración del incidente upstream. Recomendamos Performance para cualquier workload de notifications que no tolere una hora de regional outage, que es básicamente todas las notifications operativas críticas. La diferencia de precio entre Standard y Performance se amortiza la primera vez que tu PoP principal tiene incidente y el tráfico cambia transparentemente, lo que pasa estadísticamente 1-3 veces al año dependiendo de la región.
¿Cómo se gestiona el fanout a múltiples proveedores en un evento crítico?
Cuando un único evento dispara fanout (status page incident → 50K customer alerts simultáneos, deploy completado → 10K developer notifications, market move → 200K subscriber alerts), la dinámica con proveedores de buzón cambia. Enviar 50K mensajes en 5 minutos a una mezcla de Gmail, Outlook 365, Yahoo y Exchange corporativos está bien para Gmail (acepta esa tasa con pool adecuado), pero Outlook rate-limita por dominio remitente y Yahoo defiere si su backend ve un spike. Nuestro scheduler suaviza la tasa per-proveedor automáticamente para que ningún proveedor reciba el burst completo de una vez: si tienes 50K mensajes para enviar y tu pool tiene capacidad sostenida de 5K/min, el scheduler distribuye el burst en 10-12 minutos repartido por proveedor. El destinatario recibe el mensaje en segundos individuales, pero la cola interna evita generar un patrón que activaría defensas anti-abuse en el lado del receiver. Esto se llama smart fanout en nuestra documentación y está activo por defecto en Standard, Performance y Enterprise.
Patrones de digest: el caso especial de notificaciones agrupadas.
Algunas notificaciones son por naturaleza digest: el resumen diario de actividad, la lista semanal de mentions, el reporte de las últimas 24 horas. Estas no tienen la urgencia per-mensaje de las alertas operativas, pero sí tienen un patrón de envío masivo concentrado en una ventana corta (típicamente entre 7:00 y 9:00 hora local del destinatario). El reto operativo es enviar a una base de 1-10M destinatarios en distintos husos horarios y respetar el "envía a las 8:00 hora local de cada usuario" sin que el envío total se concentre en pocas horas UTC que saturarían los pools. Soportamos timezone-aware scheduling: pasas a la API el timestamp deseado en UTC más la timezone preferida del destinatario, y nuestra cola calcula el momento real de envío y lo distribuye a lo largo de las 24 horas siguiendo el patrón geográfico de tu base. Para una base global con 50% USA, 30% UE, 20% APAC, el envío real se reparte en 3 picos suaves entre 12:00-16:00 UTC, 06:00-09:00 UTC y 22:00-01:00 UTC respectivamente, lo que mantiene cada pico bajo el headroom de 2× sin throttling.
¿Cómo se integra con PagerDuty, Opsgenie y status pages?
El uso más crítico de notifications es el de incidentes operativos: cuando tu plataforma tiene un incidente, los suscriptores de tu status page reciben emails inmediatos, los oncall de tus clientes reciben page emails (si has integrado con su sistema), y tu propio equipo recibe escalation emails. La latencia importa más aquí que en cualquier otro lugar: un minuto de retraso en el incident notification puede significar que un cliente entera por Twitter antes que por email, lo que daña la confianza. Integramos con PagerDuty, Opsgenie y los status page providers más comunes (Statuspage de Atlassian, Better Stack, Instatus, Cachet) via webhooks bidireccionales: ellos disparan el evento, nosotros entregamos los mensajes, las acks vuelven a tu sistema para que tu dashboard muestre cuántos suscriptores recibieron y cuántos hicieron click. Para Performance y Enterprise, nuestro propio on-call está suscrito a alertas de degradación de tu cuenta —si tu latencia o entrega cae, paginamos a nuestro ingeniero en 5 minutos antes de que tú escribas el ticket.