Diseñar un servicio de notificaciones escalable

Un servicio de notificaciones escalable debe construirse como una plataforma asíncrona y basada en eventos que separe la ingesta de eventos, la evaluación de preferencias, la persistencia de notificaciones, la entrega específica del canal y el seguimiento de la entrega. El principio de diseño más importante es que los sistemas de productos de origen, como seguidores, me gusta, comentarios y mensajes directos, no deben llamar de forma síncrona a los proveedores de notificaciones push móviles o a los dispositivos de los usuarios. Deben publicar eventos duraderos en una capa de mensajería, y la plataforma de notificaciones debe procesar esos eventos de forma independiente con sólidas garantías de reintento e idempotencia. A un alto nivel, la arquitectura contiene estos componentes: productores de eventos, una API de ingesta, un registro de eventos duradero, procesadores de notificaciones, un servicio de preferencias del usuario, un servicio de plantillas y personalización, un almacén de notificaciones, colas de distribución por canal, trabajadores de entrega específicos del canal, integraciones de proveedores de terceros, una puerta de enlace en tiempo real para la entrega dentro de la aplicación e infraestructura de observabilidad/reintentos. Los servicios de producto generan eventos de notificación cuando ocurren acciones dirigidas al usuario. Por ejemplo, el servicio de grafo social emite un evento de nuevo seguidor, el servicio de publicaciones emite un evento de me gusta o comentario, y el servicio de mensajería emite un evento de mensaje directo. Cada evento contiene un ID de evento, tipo de evento, ID de usuario actor, ID de usuario destinatario o conjunto de destinatarios, ID de objeto, marca de tiempo de creación y metadatos necesarios para la representación. Los productores envían estos eventos a una API de ingesta de notificaciones o directamente a un bus de mensajes duradero. La API de ingesta valida el esquema, autentica al productor, asigna o verifica una clave de idempotencia y escribe el evento en el registro duradero antes de confirmar al productor. Esto evita la pérdida de notificaciones si los procesadores posteriores fallan. Para la columna vertebral de mensajería duradera, usaría Apache Kafka, Amazon MSK, Google Pub/Sub o Pulsar. Kafka/Pulsar son buenas opciones porque proporcionan alto rendimiento, ordenación particionada, retención, reproducción, grupos de consumidores y almacenamiento duradero. A 50.000 solicitudes de notificación por segundo, el flujo de eventos debe particionarse por ID de usuario destinatario para el orden a nivel de usuario cuando sea necesario, o por ID de evento cuando el orden estricto por usuario sea menos importante. La partición por destinatario ayuda a evitar notificaciones dentro de la aplicación fuera de orden para un solo usuario, pero puede crear particiones calientes para cuentas de celebridades o eventos grupales. Para casos de distribución masiva, como un evento que produce notificaciones a millones de seguidores, un servicio de distribución masiva separado debe dividir a los destinatarios en lotes y publicar trabajos de notificación derivados por destinatario en muchas particiones. Los procesadores de notificaciones consumen eventos sin procesar del registro de eventos duradero. Sus responsabilidades son determinar los destinatarios, obtener las preferencias del usuario, aplicar límites de velocidad y horas de silencio, desduplicar eventos, generar registros de notificación específicos del canal y publicar trabajos de entrega. Para eventos directos como un comentario en la publicación de un usuario, el conjunto de destinatarios es pequeño. Para eventos de distribución masiva como la publicación de una celebridad, el procesador debe evitar hacer toda la distribución de forma síncrona. Debe crear un trabajo de distribución masiva y procesar los destinatarios en fragmentos, utilizando lecturas por lotes del almacén de grafos sociales. Esto evita que un evento muy grande bloquee la ruta de baja latencia para las notificaciones normales. El servicio de preferencias del usuario almacena la configuración, como si un usuario desea notificaciones push, dentro de la aplicación o por correo electrónico para me gusta, comentarios, seguidores y mensajes directos. Las preferencias deben almacenarse en una base de datos de alta disponibilidad como DynamoDB, Cassandra, ScyllaDB o una base de datos relacional fragmentada. El patrón de acceso es principalmente búsqueda de clave-valor por ID de usuario y tipo de notificación, por lo que un almacén distribuido de clave-valor o de columnas anchas es apropiado. Para cumplir el objetivo de latencia de 2 segundos, las preferencias también deben almacenarse en caché en Redis, Memcached o una caché local en memoria con TTL cortos. Las actualizaciones de preferencias se escriben en la fuente de verdad de la base de datos y se propagan a las cachés mediante eventos de invalidación. La contrapartida es que la antigüedad de la caché puede hacer que una preferencia cambiada recientemente tarde unos segundos en aplicarse; si se requiere una consistencia estricta de las preferencias, los procesadores pueden leer directamente de la base de datos en caso de fallo de caché o para usuarios actualizados recientemente. El servicio de plantillas y personalización representa el contenido de las notificaciones. Mapea tipos de eventos a plantillas como "Alex le dio me gusta a tu publicación" o "Maya comentó: ...". Maneja la localización, los enlaces profundos, las URL de imágenes y las restricciones de carga útil específicas del canal. Las definiciones de plantillas se pueden almacenar en una base de datos de configuración y almacenar en caché de forma agresiva, ya que cambian con poca frecuencia. La representación debe realizarse antes de publicar los trabajos de entrega para que cada trabajo sea autónomo y se pueda reintentar de forma segura. El almacén de notificaciones es la fuente de verdad para las notificaciones dentro de la aplicación visibles para el usuario y el estado de entrega. Una buena opción es Cassandra, DynamoDB, ScyllaDB u otro almacén escalable horizontalmente particionado por ID de usuario destinatario y ordenado por marca de tiempo de notificación. El patrón de acceso principal es "obtener las últimas notificaciones para el usuario X", por lo que la tabla puede usar recipient_user_id como clave de partición y created_at o notification_id como clave de ordenación. El servicio escribe un registro de notificación dentro de la aplicación antes o de forma atómica con la publicación del trabajo de entrega dentro de la aplicación. Los registros incluyen ID de notificación, destinatario, tipo, contenido, estado, estado de leído/no leído, marcas de tiempo y clave de desduplicación. Este almacén garantiza que, incluso si la entrega de WebSocket falla, el usuario aún pueda ver la notificación al abrir la aplicación. Después de aplicar las preferencias y las plantillas, el procesador publica trabajos en colas de canal separadas: cola push, cola dentro de la aplicación y cola de correo electrónico. Separar las colas es importante porque cada canal tiene diferentes características de latencia y confiabilidad. Las colas push y dentro de la aplicación son sensibles a la latencia y deben aprovisionarse para un alto rendimiento con una cola mínima. El correo electrónico es menos sensible a la latencia y puede tolerar retrasos más largos, limitación de proveedores y procesamiento por lotes. Las colas separadas también evitan que un proveedor de correo electrónico lento afecte la entrega push. Los trabajadores de entrega push consumen de la cola push y envían notificaciones a Apple Push Notification service, Firebase Cloud Messaging u otros proveedores de notificaciones push móviles. Los tokens de dispositivo se almacenan en un registro de dispositivos indexado por ID de usuario, con token, plataforma, versión de la aplicación, idioma y marca de tiempo de la última vez visto. El registro puede usar un almacén distribuido de clave-valor y almacenar en caché los tokens activos. Los trabajadores push deben manejar las respuestas del proveedor, eliminar tokens no válidos, reintentar fallos transitorios con retroceso exponencial y registrar los intentos de entrega. Los acuses de recibo del proveedor push no garantizan que el usuario haya visto la notificación, solo que el proveedor la aceptó, por lo que el sistema debe distinguir la aceptación del proveedor de la recepción real del usuario. La entrega dentro de la aplicación tiene dos rutas. Primero, la notificación se persiste en el almacén de notificaciones. Segundo, un trabajador de entrega dentro de la aplicación la envía a los dispositivos actualmente conectados del usuario a través de una puerta de enlace en tiempo real. La puerta de enlace se puede implementar utilizando WebSockets, flujos HTTP/2 o una infraestructura de conexión persistente similar a la de notificaciones push móviles. Los nodos de la puerta de enlace mantienen el estado de conexión del usuario en memoria y publican información de presencia en un servicio de presencia distribuido. Una capa de enrutamiento o un mapa de presencia basado en Redis/NATS indica al trabajador dentro de la aplicación qué nodo de la puerta de enlace posee actualmente la conexión de un usuario. Si el usuario está desconectado o falla el envío de la puerta de enlace, no se pierde ninguna notificación porque la notificación persistida se obtendrá a través de la API de la bandeja de entrada de notificaciones de la aplicación en la próxima sesión. Para baja latencia, los nodos de la puerta de enlace deben implementarse regionalmente cerca de los usuarios y la cola dentro de la aplicación debe ser procesada por trabajadores en la misma región siempre que sea posible. Los trabajadores de entrega de correo electrónico consumen de la cola de correo electrónico y envían a través de proveedores como SES, SendGrid o Mailgun. Deben admitir la conmutación por error del proveedor, el manejo de rebotes, las listas de supresión, el cumplimiento de la cancelación de suscripción y los límites de velocidad por proveedor. Las notificaciones por correo electrónico se pueden agrupar o resumir para tipos de eventos de baja prioridad como los me gusta, mientras que los mensajes directos o los eventos relacionados con la seguridad pueden enviarse de inmediato. Dado que el correo electrónico es más lento y costoso, las preferencias del usuario y la limitación de velocidad son especialmente importantes. La confiabilidad se logra mediante escrituras duraderas, procesamiento al menos una vez, idempotencia, reintentos y colas de mensajes fallidos. La capa de ingesta solo confirma a los productores después de que el evento se escribe de forma duradera en Kafka/Pulsar. Los consumidores confirman los offsets solo después de haber escrito con éxito los registros de notificación y publicado los trabajos de canal posteriores. Dado que los reintentos pueden crear duplicados, cada evento y notificación debe tener claves de idempotencia estables. Por ejemplo, una clave de notificación de me gusta podría ser recipient_id + actor_id + post_id + event_type, mientras que una clave de notificación de comentario podría incluir comment_id. El almacén de notificaciones garantiza la unicidad de esta clave, o los procesadores realizan escrituras condicionales. Los trabajadores de entrega también deben usar IDs de intento y transiciones de estado idempotentes para que los trabajos duplicados no creen registros dentro de la aplicación duplicados o correos electrónicos duplicados cuando sea evitable. El sistema garantiza la entrega al menos una vez, no exactamente una vez, por lo que los clientes también deben desduplicar por ID de notificación. Se requieren colas de mensajes fallidos para mensajes venenosos, eventos mal formados, fallos repetidos del proveedor o registros que no se pueden representar. Una herramienta de reproducción debe permitir a los operadores solucionar problemas y reprocesar eventos del registro duradero original o de la cola de mensajes fallidos. La retención de Kafka debe ser lo suficientemente larga para admitir la recuperación operativa, por ejemplo, varios días. Los metadatos críticos y el estado de entrega también deben persistirse en la base de datos de notificaciones para fines de auditoría. Para cumplir con el requisito de escala de 100 millones de usuarios activos diarios y 50.000 solicitudes de notificación por segundo, todos los servicios principales deben ser escalables horizontalmente y sin estado siempre que sea posible. Las API de ingesta se escalan detrás de balanceadores de carga. Los temas de Kafka/Pulsar están particionados lo suficientemente amplios como para admitir el rendimiento máximo y el paralelismo de los consumidores. Los procesadores y los trabajadores de entrega se ejecutan en grupos de escalado automático o implementaciones de Kubernetes y escalan según el rezago de la cola, la CPU, la latencia del proveedor y la tasa de solicitudes. Las bases de datos se particionan por ID de usuario para distribuir la carga. Los problemas de claves calientes deben manejarse con trabajos de distribución fragmentados, manejo especial de usuarios celebridades y contrapresión. Para una distribución masiva extremadamente grande, el sistema puede usar distribución pull para notificaciones de baja prioridad: en lugar de escribir una notificación por seguidor de inmediato, almacena el evento una vez y lo materializa cuando un usuario abre la aplicación. Esto reduce la amplificación de escritura pero aumenta la complejidad de lectura y puede no ser apropiado para mensajes directos o comentarios. El objetivo de latencia de 2 segundos para el 99% de las notificaciones push y dentro de la aplicación se cumple manteniendo la ruta crítica corta: productor a registro duradero, búsqueda de preferencias del procesador desde la caché, escritura del registro de notificación, publicación en la cola del canal y entrega inmediata por trabajadores activos. Los trabajadores push y dentro de la aplicación deben estar sobrerre-aprovisionados para la carga máxima, y las colas deben usar carriles de prioridad para que los mensajes directos y los comentarios se procesen antes que los me gusta de baja prioridad. La implementación regional reduce la latencia de la red. Para usuarios en múltiples regiones, el enrutamiento puede basarse en la región de origen del destinatario, con replicación entre regiones para recuperación ante desastres. El diseño debe medir la latencia de extremo a extremo desde la creación del evento hasta la aceptación del proveedor o el envío de la puerta de enlace, no solo el tiempo de procesamiento interno. La observabilidad es esencial. La plataforma debe rastrear la tasa de solicitudes, el rezago de la cola por partición, la latencia de procesamiento, la tasa de aciertos de la caché de preferencias, los fallos de creación de notificaciones, las tasas de error del proveedor, los recuentos de reintentos, el volumen de mensajes fallidos, el éxito de la entrega de WebSocket, la latencia de aceptación del proveedor push y la latencia de extremo a extremo p50/p95/p99. El rastreo distribuido debe transportar el ID de evento original a través de cada componente. Las alertas deben activarse ante el crecimiento del rezago de la cola, fallos elevados, limitación de proveedores, latencia de escritura de la base de datos y SLO de latencia incumplidos. Existen varias compensaciones. Kafka o Pulsar agregan complejidad operativa pero proporcionan la durabilidad, la reproducción y el rendimiento necesarios para la entrega al menos una vez a esta escala. Cassandra o DynamoDB proporcionan alta escalabilidad de escritura y disponibilidad, pero ofrecen consultas ad hoc limitadas, por lo que los análisis deben enviarse a un almacén de datos separado. El almacenamiento en caché de preferencias mejora la latencia pero introduce problemas de consistencia de corta duración. La entrega al menos una vez es mucho más simple y confiable que la entrega exactamente una vez, pero el sistema debe tolerar duplicados utilizando claves de idempotencia y desduplicación del lado del cliente. La distribución al escribir (fanout-on-write) proporciona lecturas rápidas de la bandeja de entrada pero puede ser costosa para eventos de alto número de seguidores; la distribución al leer (fanout-on-read) ahorra escrituras pero complica la clasificación y la materialización en el momento de la lectura. Un modelo híbrido suele ser el mejor: distribución al escribir para notificaciones directas, importantes y de volumen normal, y distribución al leer o distribución por lotes para eventos masivos de baja prioridad. En resumen, el servicio debe utilizar una arquitectura duradera basada en eventos con flujos de mensajes particionados, procesadores sin estado, búsquedas de preferencias en caché, almacenamiento persistente de notificaciones, colas de canal separadas, trabajadores específicos del canal y mecanismos sólidos de reintento/idempotencia. Este diseño se escala horizontalmente a 50.000 solicitudes de notificación por segundo, mantiene la entrega push y dentro de la aplicación dentro del objetivo p99 de 2 segundos a través de la caché y colas de baja latencia, y garantiza que las notificaciones no se pierdan al persistir eventos y registros de notificación antes de confirmar el progreso.

## Arquitectura de Servicio de Notificaciones Escalable ### Descripción General del Sistema El servicio de notificaciones está diseñado como un sistema distribuido y basado en eventos que procesa notificaciones de forma asíncrona para manejar 50,000 solicitudes por segundo con una latencia inferior a 2 segundos para el 99% de las entregas. La arquitectura sigue un patrón de microservicios con una clara separación de responsabilidades. ### Arquitectura de Alto Nivel ``` Fuentes de Eventos → API Gateway → Servicio de Notificaciones → Cola de Mensajes → Trabajadores de Entrega ↓ Servicio de Preferencias ↓ Capa de Caché (Redis) ↓ Base de Datos (PostgreSQL) ``` ### Componentes Clave #### 1. API Gateway - **Responsabilidad:** Punto de entrada para todas las solicitudes de notificación. Maneja limitación de tasa, autenticación y validación de solicitudes. - **Tecnología:** NGINX o AWS API Gateway - **Razón:** Proporciona un único punto de entrada, permite la limitación de tráfico para evitar sobrecargas y distribuye el tráfico entre los servicios backend. #### 2. Servicio de Notificaciones (Procesamiento Central) - **Responsabilidad:** Recibe eventos de notificación, los valida, los enriquece con las preferencias del usuario y los publica en la cola de mensajes. - **Tecnología:** Microservicio sin estado (Node.js, Go o Java) - **Características Clave:** - Valida la carga útil de la notificación - Obtiene las preferencias del usuario de la caché - Determina los canales de notificación (push, in-app, email) según la configuración del usuario - Publica notificaciones enriquecidas en la cola de mensajes - **Escalabilidad:** Escalable horizontalmente; múltiples instancias detrás de un balanceador de carga #### 3. Cola de Mensajes (Bus de Eventos) - **Tecnología:** Apache Kafka o AWS SQS/SNS - **Razón:** - Desacopla la generación de notificaciones de la entrega - Proporciona durabilidad y capacidad de repetición para garantizar la entrega al menos una vez - Permite el procesamiento paralelo de notificaciones - Maneja picos de tráfico al almacenar temporalmente las solicitudes - **Configuración:** Múltiples particiones (ej. 100-200) para permitir el consumo paralelo - **Estructura de Temas:** Temas separados para notificaciones push, in-app y de correo electrónico para permitir una escalabilidad independiente #### 4. Servicio de Preferencias - **Responsabilidad:** Gestiona las preferencias y configuraciones de notificación del usuario. - **Tecnología:** Microservicio con backend PostgreSQL - **Características:** - Almacena las preferencias del usuario (tipos de notificación, canales, límites de frecuencia) - Proporciona una API para que los usuarios actualicen sus preferencias - Almacena en caché las preferencias en Redis para un acceso rápido - **Escalabilidad:** Servicio con alta carga de lectura; el almacenamiento en caché reduce significativamente la carga de la base de datos #### 5. Capa de Caché - **Tecnología:** Redis Cluster - **Propósito:** - Almacena en caché las preferencias del usuario (TTL: 1 hora) - Almacena en caché los tokens de dispositivos de usuario para notificaciones push - Almacena contadores de limitación de tasa - Reduce las consultas a la base de datos en más del 90% - **Razón:** Latencia inferior a milisegundos para la búsqueda de preferencias #### 6. Trabajadores de Entrega - **Trabajador de Notificaciones Push:** - Consume del tema push - Se integra con FCM (Firebase Cloud Messaging) y APNs (Apple Push Notification service) - Maneja la gestión de tokens de dispositivo y la limpieza de tokens inválidos - Implementa retroceso exponencial para reintentos - **Trabajador de Notificaciones In-App:** - Consume del tema in-app - Almacena notificaciones en una base de datos de series temporales (ej. Cassandra o ClickHouse) - Publica en servidores WebSocket para entrega en tiempo real - Mantiene el estado de notificación leído/no leído - **Trabajador de Notificaciones por Correo Electrónico:** - Consume del tema de correo electrónico - Agrupa correos electrónicos para mayor eficiencia - Se integra con el servicio de correo electrónico (SendGrid, AWS SES) - Implementa limitación de tasa para evitar filtros de spam #### 7. Servidor WebSocket - **Responsabilidad:** Mantiene conexiones persistentes con clientes móviles y web para notificaciones in-app en tiempo real. - **Tecnología:** Node.js con Socket.io o Go con gorilla/websocket - **Escalabilidad:** Servidores sin estado; utiliza pub/sub de Redis para comunicación entre servidores - **Respaldo:** Long-polling HTTP para clientes que no admiten WebSocket #### 8. Almacén de Notificaciones (Base de Datos de Series Temporales) - **Tecnología:** Cassandra o ClickHouse - **Propósito:** Almacena todas las notificaciones para auditoría, análisis e historial de notificaciones del usuario - **Razón:** Optimizado para cargas de trabajo con alta escritura y consultas por rango de tiempo - **Retención:** 90 días de historial de notificaciones #### 9. Registro de Dispositivos de Usuario - **Tecnología:** Redis + PostgreSQL - **Propósito:** Mantiene el mapeo de usuarios a sus dispositivos y tokens push - **Características:** - Rastrea el registro/anulación de registro de dispositivos - Almacena metadatos del dispositivo (SO, versión de la aplicación) - Maneja la actualización y anulación de tokens ### Flujo de Datos 1. **Ingesta de Eventos:** Las fuentes de eventos (acciones del usuario, eventos del sistema) envían solicitudes de notificación al API Gateway 2. **Validación y Enriquecimiento:** El Servicio de Notificaciones valida la carga útil y obtiene las preferencias del usuario de la caché 3. **Determinación de Canal:** Basado en las preferencias, la notificación se dirige al tema apropiado (push, in-app, email) 4. **Encolamiento:** La Cola de Mensajes almacena temporalmente las notificaciones y garantiza la durabilidad 5. **Entrega:** Trabajadores especializados consumen de los temas y entregan a través de los canales respectivos 6. **Acuse de Recibo:** Los trabajadores de entrega confirman la entrega exitosa y actualizan el estado de la notificación ### Cumplimiento de Requisitos #### Escalabilidad (50,000 req/seg) - **Escalado Horizontal:** Todos los componentes son sin estado y escalables horizontalmente - **Particionamiento de la Cola de Mensajes:** Temas de Kafka particionados entre múltiples brokers; cada partición puede manejar ~500-1000 req/seg - **Fragmentación de Base de Datos:** Datos de usuario fragmentados por user_id para distribuir la carga - **Estrategia de Caché:** Redis almacena en caché los datos