Recorrido por un servicio de notificaciones: canales, preferencias, intentos de entrega y reintentos

Objetivo

Entregar mensajes de muchos productores a los usuarios a través de varios canales según sus preferencias, de modo que ningún productor hable directamente con un proveedor y un reintento nunca envíe el mensaje dos veces.

Requisitos previos

Una lista de canales (correo electrónico, push, SMS, in-app) y sus proveedores, un catálogo de tipos de notificación con un canal por defecto y una urgencia por tipo, y una política sobre qué puede desactivar un usuario.

Pasos

1. Restricciones: los productores no deben bloquearse esperando la entrega; los proveedores fallan de forma independiente; para la mayoría de los tipos, un duplicado es peor que un retraso; las campañas masivas no deben retrasar los mensajes transaccionales.
2. Componentes: una API de ingesta que acepta (idempotency_key, recipient, type, payload) y escribe una fila antes de responder; un enrutador que expande una notificación en entregas por canal tras comprobar las preferencias y las horas de silencio; una cola por canal; workers de canal que renderizan las plantillas y llaman a los proveedores; un receptor de callbacks para rebotes, quejas y tokens inválidos.
3. Modelo de datos: notification(id, idempotency_key unique, recipient, type, payload, created_at); delivery(id, notification_id, channel, address, status, attempts, next_attempt_at, provider_message_id, last_error); preference(recipient, type, channel, enabled); device_token(recipient, token, platform, invalidated_at). La clave única hace inofensivos los reintentos del productor.
4. Reintentos: cada canal tiene su propio calendario de backoff con jitter y un máximo; los errores del proveedor se clasifican como reintentables (timeouts, 5xx, límites de tasa) o terminales (dirección inválida, dado de baja). Para Web Push, el RFC 8030 exige un encabezado TTL en segundos en cada solicitud de entrega, y establece que, una vez transcurrido, el servicio de push no debe intentar la entrega; una notificación urgente debería llevar un TTL corto en lugar de reintentarse durante horas después de dejar de ser útil.
5. Modos de fallo: un worker que falla después de que el proveedor aceptó el mensaje pero antes de actualizar la fila (un duplicado; conviene conservar el id de mensaje del proveedor y preferir proveedores con API de envío idempotentes); una caída del proveedor que hace crecer la cola pendiente (descartar por antigüedad los tipos sensibles al tiempo, en lugar de entregarlos tarde); una plantilla que falla para un idioma concreto (hacer fallar esa entrega, no el worker); campañas que dejan sin recursos al tráfico transaccional (colas o prioridades separadas); tokens invalidados en silencio (procesar los callbacks y depurar).
6. Medir: el tiempo desde la ingesta hasta la aceptación del proveedor por canal, los intentos por entrega, la tasa de fallo terminal por clase de error, la antigüedad de la cola, la tasa de exclusión voluntaria por tipo.
7. No es prioritario: la conmutación entre varios proveedores, los resúmenes y el agrupamiento por lotes, los topes de tasa por usuario, un editor de plantillas, la analítica de interacción, los experimentos de redacción.

Resultado esperado

Los productores llaman a una sola API; cada entrega queda confirmada por un proveedor, falla de forma terminal con un motivo, o sigue programada; repetir una solicitud del productor no produce un segundo mensaje.

Límites y base de verificación

Diseño propuesto, sin mediciones. La supresión de duplicados en el límite del proveedor depende del proveedor; sin una API de envío idempotente, el diseño acepta duplicados poco frecuentes tras una caída.