Diseño de un servicio de notificaciones en tiempo real

Servicio de Notificaciones en Tiempo Real — Diseño de Sistema de Alto Nivel ================================================================================ 0. ESTIMACIÓN APROXIMADA ================================================================================ - 10M DAU × 20 notificaciones/usuario/día = 200M notificaciones/día - 200M / 86,400s ≈ 2,315 notificaciones/segundo (promedio) - Carga pico (asumiendo 5× promedio) ≈ 11,575 notificaciones/segundo - Cada carga útil de notificación ~1 KB → ~200 GB/día de ingesta de datos brutos - Presupuesto de latencia: < 2 segundos de extremo a extremo (ingesta → entrega al dispositivo) ================================================================================ 1. ARQUITECTURA CENTRAL ================================================================================ El sistema sigue una arquitectura de microservicios impulsada por eventos con los siguientes componentes clave: ┌──────────────┐ │ Productores │ (Servicio de Likes, Servicio de Comentarios, Servicio de Seguidores, etc.) └──────┬───────┘ │ Evento de Notificación (gRPC / mensaje asíncrono) ▼ ┌──────────────────┐ │ API Gateway / │ Limitación de tasa, autenticación, enrutamiento │ Balanceador de │ (p. ej., AWS ALB / Envoy / Kong) │ Carga │ └──────┬───────────┘ │ ▼ ┌──────────────────┐ │ Servicio de │ Servicio sin estado (escalable horizontalmente) │ Notificación (SN)│ - Valida y desduplica eventos │ │ - Enriquece con preferencias del usuario │ │ - Distribuye a colas por canal └──────┬───────────┘ │ Escribe el registro de notificación en la BD │ Publica en la Cola de Mensajes ▼ ┌──────────────────────────────────────────────────┐ │ Cola de Mensajes / Broker │ │ (Apache Kafka — particionado por hash de user_id)│ │ │ │ Temas: push_notifications │ │ email_notifications │ │ in_app_notifications │ └──┬──────────────┬─────────────────┬──────────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ Worker │ │ Worker │ │ Worker │ │ Push │ │ Email │ │ In-App │ │ Pool │ │ Pool │ │ Pool │ └───┬────┘ └────┬─────┘ └───────┬────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ APNs / │ │ SES / │ │ Pasarela │ │ FCM │ │ SendGrid │ │ WebSocket │ └────────┘ └──────────┘ │ (conexiones │ │ persistentes) │ └────────────────┘ Descripciones de Componentes: A) API Gateway / Balanceador de Carga - Punto de entrada para servicios productores internos y llamadas a API externas (p. ej., marcar como leído). - Maneja la limitación de tasa, la autenticación y el enrutamiento de solicitudes. - Distribuye el tráfico entre múltiples instancias del Servicio de Notificación. B) Servicio de Notificación (SN) - Microservicio sin estado desplegado en múltiples réplicas detrás del balanceador de carga. - Recibe eventos de notificación, los valida, realiza la desduplicación (verificación de clave de idempotencia). - Busca las preferencias de notificación del usuario en una caché (Redis) o base de datos. - Determina en qué canales entregar (push, email, in-app) según las preferencias. - Persiste el registro de notificación en la base de datos. - Publica mensajes específicos del canal en temas de Kafka. C) Cola de Mensajes (Apache Kafka) - Desacopla la creación de notificaciones de la entrega, absorbiendo picos de tráfico. - Particionado por hash de user_id para preservar el orden por usuario. - Proporciona durabilidad (factor de replicación = 3) y capacidad de repetición. - Temas separados por canal permiten la escalabilidad independiente de los consumidores. D) Workers de Canal (Grupos de Consumidores) - Pool de Workers Push: Consume del tema push_notifications, agrupa solicitudes y envía a APNs (iOS) y FCM (Android). Maneja la gestión de tokens y la lógica de reintentos. - Pool de Workers de Email: Consume del tema email_notifications, renderiza plantillas y envía a través de SES/SendGrid. Implementa retroceso exponencial para fallos transitorios. - Pool de Workers In-App: Consume del tema in_app_notifications, envía a la Pasarela WebSocket para entrega en tiempo real. Vuelve a sondeo si WebSocket está desconectado. E) Pasarela WebSocket - Mantiene conexiones WebSocket persistentes con usuarios en línea. - Escalada horizontalmente; utiliza Redis Pub/Sub o un bus de mensajes compartido para que cualquier nodo de pasarela pueda entregar a cualquier usuario conectado. - Registro de conexiones almacenado en Redis (mapeo user_id → gateway_node). F) API de Lectura de Notificaciones - Ruta de lectura separada para obtener el historial de notificaciones, marcar como leído, gestionar preferencias. - Servida desde réplicas de lectura / caché para evitar afectar la ruta de escritura. ================================================================================ 2. ESQUEMA DE BASE DE DATOS ================================================================================ Almacén de datos principal: PostgreSQL (para preferencias y metadatos) + Cassandra (para almacenamiento de notificaciones a escala). --- PostgreSQL (Preferencias y Metadatos de Usuario) --- TABLA: users user_id UUID PRIMARY KEY email VARCHAR(255) phone VARCHAR(50) created_at TIMESTAMP updated_at TIMESTAMP TABLA: notification_preferences user_id UUID PRIMARY KEY REFERENCES users(user_id) push_enabled BOOLEAN DEFAULT TRUE email_enabled BOOLEAN DEFAULT TRUE in_app_enabled BOOLEAN DEFAULT TRUE quiet_hours_start TIME NULLABLE quiet_hours_end TIME NULLABLE email_digest_freq ENUM('instant', 'hourly', 'daily') DEFAULT 'instant' -- Sobrescrituras por categoría likes_push BOOLEAN DEFAULT TRUE likes_email BOOLEAN DEFAULT FALSE comments_push BOOLEAN DEFAULT TRUE comments_email BOOLEAN DEFAULT TRUE follows_push BOOLEAN DEFAULT TRUE follows_email BOOLEAN DEFAULT FALSE mentions_push BOOLEAN DEFAULT TRUE mentions_email BOOLEAN DEFAULT TRUE updated_at TIMESTAMP TABLA: device_tokens token_id UUID PRIMARY KEY user_id UUID REFERENCES users(user_id) platform ENUM('ios', 'android', 'web') device_token VARCHAR(512) is_active BOOLEAN DEFAULT TRUE created_at TIMESTAMP updated_at TIMESTAMP INDEX idx_device_user (user_id) --- Cassandra (Almacenamiento de Notificaciones — optimizado para lecturas de series temporales) --- TABLA: notifications user_id UUID -- Clave de partición created_at TIMEUUID -- Clave de agrupación (DESC) notification_id UUID type TEXT -- 'like', 'comment', 'follow', 'mention', 'system' actor_id UUID target_entity_type TEXT -- 'post', 'comment', 'profile' target_entity_id UUID message TEXT is_read BOOLEAN channels_delivered SET<TEXT> -- {'push', 'email', 'in_app'} metadata TEXT -- Blob JSON para extensibilidad PRIMARY KEY ((user_id), created_at) WITH CLUSTERING ORDER BY (created_at DESC) AND default_time_to_live = 7776000 -- TTL de 90 días TABLA: notification_counts (tabla de contadores/materializada) user_id UUID PRIMARY KEY unread_count COUNTER --- Redis (Capa de Caché) --- - Caché de preferencias de usuario: Clave = pref:{user_id}, TTL = 10 min - Caché de recuento no leído: Clave = unread:{user_id}, TTL = 5 min - Conjunto de desduplicación: Clave = dedup:{idempotency_key}, TTL = 24 horas - Registro de conexión WebSocket: Clave = ws:{user_id} → id_nodo_pasarela ================================================================================ 3. ESTRATEGIA DE ESCALADO ================================================================================ A) Escalado Horizontal de Servicios sin Estado - Servicio de Notificación, todos los Pools de Workers y la Pasarela WebSocket no tienen estado y son escalables horizontalmente. - Grupos de autoescalado (HPA de Kubernetes) basados en métricas de CPU, memoria y latencia de cola. - Objetivo: cada instancia de SN maneja ~500 req/s; se necesitan ~25 instancias en pico. B) Particionamiento de Kafka - Comenzar con 64 particiones por tema (permite hasta 64 consumidores por grupo). - Particionar por hash de user_id para garantías de orden por usuario. - Escalar particiones a medida que crece el rendimiento (reparticionar con cuidado). - Grupos de consumidores separados por canal permiten escalado independiente. C) Escalado de Base de Datos - Cassandra: Escalable horizontalmente de forma natural. Comenzar con un clúster de 6 nodos (RF=3). Añadir nodos a medida que crece el volumen de datos. La clave de partición = user_id distribuye la carga de manera uniforme. - PostgreSQL: Escalado vertical inicialmente para preferencias (conjunto de datos relativamente pequeño: 10M filas). Añadir réplicas de lectura para búsquedas de preferencias intensivas en lectura. Considerar el particionamiento por user_id si es necesario. - Clúster de Redis: 3+ nodos con particionamiento automático para caché y registro de conexiones. D) Escalado de la Pasarela WebSocket - Cada nodo de pasarela maneja ~100K conexiones concurrentes. - 10M DAU con ~30% concurrentes en línea = 3M conexiones → ~30 nodos de pasarela. - Redis Pub/Sub o un bus de mensajes ligero (p. ej., NATS) para el enrutamiento de mensajes entre nodos. - Hash consistente para la asignación de usuario a nodo con reequilibrio gradual. E) Limitación de Tasa y Contrapresión - Limitar la tasa de los productores de notificaciones para evitar abusos (p. ej., máx. 1000 eventos/segundo por productor). - Monitoreo del retraso del consumidor de Kafka con alertas; escalar automáticamente los consumidores cuando el retraso excede el umbral. - Disyuntores en servicios externos (APNs, FCM, SES) para prevenir fallos en cascada. F) Ruta de Crecimiento Futuro - Pasar a un despliegue multirregional con Kafka MirrorMaker 2 para replicación entre regiones. - Introducir una capa de agregación/agrupación de notificaciones (p. ej., "A ti y a otras 5 personas les gustó tu publicación"). - Añadir una cola de prioridad para notificaciones sensibles al tiempo (p. ej., mensajes directos frente a notificaciones de 'me gusta'). ================================================================================ 4. FIABILIDAD Y TOLERANCIA A FALLOS ================================================================================ A) Durabilidad de Datos - Kafka: Factor de replicación = 3, min.insync.replicas = 2, acks = all. Garantiza que no haya pérdida de datos incluso si falla un broker. - Cassandra: Factor de replicación = 3, consistencia de escritura = QUORUM (2 de 3). Tolera fallos de un solo nodo sin pérdida de datos. - PostgreSQL: Replicación síncrona a al menos un standby. B) Entrega Al Menos Una Vez - Los consumidores de Kafka solo confirman los offsets después del procesamiento exitoso. - Los workers implementan entrega idempotente usando notification_id como clave de desduplicación. - Si falla la entrega de push/email, el mensaje permanece en Kafka para reintentarlo. - Cola de Mensajes Muertos (DLQ) para mensajes que fallan después de N reintentos (p. ej., 5 reintentos con retroceso exponencial). C) Alta Disponibilidad (objetivo 99.9% = máximo 8.76 horas de inactividad/año) - Todos los servicios desplegados en 3 Zonas de Disponibilidad (AZs). - Kubernetes con reglas de anti-afinidad de pods asegura que las réplicas se distribuyan entre las AZs. - Clústeres de bases de datos abarcan múltiples AZs con failover automático. - Verificaciones de estado del balanceador de carga con eliminación automática de instancias no saludables. - Despliegues blue-green o canary para minimizar el tiempo de inactividad relacionado con el despliegue. D) Degradación Elegante - Si el servicio de notificaciones push (APNs/FCM) está caído, las notificaciones se ponen en cola en Kafka y se reintentan. - Si la pasarela WebSocket está sobrecargada, los clientes vuelven a consultar la API de lectura de notificaciones. - Si Cassandra no está disponible temporalmente, las notificaciones se almacenan en búfer en Kafka (que tiene retención de varios días). - Patrón de disyuntor en todas las dependencias externas con comportamiento de respaldo. E) Monitoreo y Alertas - Seguimiento de latencia de extremo a extremo: marca de tiempo de creación → marca de tiempo de entrega (P50, P95, P99). - Monitoreo del retraso del consumidor de Kafka por tema y grupo de consumidores. - Paneles de tasa de error por canal (tasa de fallos de push, tasa de rebote de email). - Alertas sobre: latencia > 2s en P95, retraso del consumidor > 10K mensajes, tasa de error > 1%, disponibilidad < 99.9%. F) Recuperación ante Desastres - Datos de temas de Kafka retenidos durante 7 días, lo que permite la repetición desde cualquier punto. - Instantáneas de Cassandra tomadas diariamente, almacenadas en S3 con replicación entre regiones. - Archivado WAL de PostgreSQL a S3 para recuperación a punto en el tiempo. - Runbook para recuperación completa del clúster con RTO objetivo < 1 hora, RPO < 5 minutos. ================================================================================ 5. COMPENSACIONES CLAVE ================================================================================ Compensación 1: Disponibilidad vs. Consistencia Estricta (AP sobre CP) Decisión: Elegimos consistencia eventual para la entrega de notificaciones y el estado de lectura. - Cassandra con escrituras QUORUM proporciona una consistencia suficientemente fuerte para las notificaciones, priorizando la disponibilidad y la tolerancia a particiones. - Un usuario podría ver brevemente un recuento no leído obsoleto (en caché en Redis con TTL de 5 minutos), pero esto es aceptable para un sistema de notificaciones donde la precisión perfecta en tiempo real de los recuentos no es crítica. - La alternativa — usar una base de datos fuertemente consistente como PostgreSQL para todo el almacenamiento de notificaciones — crearía un cuello de botella de escalado a 200M escrituras/día y arriesgaría la disponibilidad durante particiones de red. - Impacto: Los usuarios pueden ver ocasionalmente un recuento de notificaciones que difiere en 1-2 durante unos segundos. Este es un problema menor de UX en comparación con el riesgo de que todo el sistema de notificaciones se vuelva inaccesible. Compensación 2: Modelo Push (WebSockets) vs. Modelo Pull (Polling) para Notificaciones In-App Decisión: Elegimos un modelo push-first usando WebSockets con sondeo como respaldo. - Push a través de WebSockets entrega notificaciones en tiempo real (subsegundo) cumpliendo nuestro requisito de latencia <2s. - Sin embargo, mantener millones de conexiones persistentes consume muchos recursos (~30 nodos de pasarela para 3M conexiones concurrentes) y añade complejidad operativa (gestión de conexiones, heartbeats, lógica de reconexión). - La alternativa — sondeo puro — sería más simple de operar pero aumentaría la latencia (si el intervalo de sondeo es largo) o la carga del servidor drásticamente (si el intervalo de sondeo es corto). Con 3M de usuarios concurrentes sondeando cada 2 segundos = 1.5M req/s solo para sondeo, lo cual es mucho más costoso que mantener conexiones WebSocket. - Compromiso: Usamos WebSockets para usuarios en línea y volvemos al sondeo (con intervalos más largos) cuando no se pueden establecer conexiones WebSocket (p. ej., firewalls restrictivos). Las notificaciones push a través de APNs/FCM manejan el caso en que el usuario está desconectado. Compensación 3: Almacén de Notificaciones Único (Cassandra) vs. Persistencia Políglota Decisión: Usamos Cassandra para el almacenamiento de notificaciones y PostgreSQL para las preferencias/metadatos del usuario en lugar de una única base de datos para todo. - Cassandra sobresale en escrituras de series temporales de alto rendimiento (200M/día) y lecturas basadas en clave de partición (obtener notificaciones para un usuario), que es el patrón de acceso dominante. - PostgreSQL es más adecuado para la naturaleza relacional de las preferencias del usuario (joins con la tabla de usuarios, actualizaciones transaccionales de preferencias). - La compensación es una mayor complejidad operativa (dos sistemas de bases de datos para mantener, monitorear y respaldar) y la necesidad de mantener los datos consistentes entre sistemas (p. ej., si se elimina un usuario, las notificaciones deben limpiarse en Cassandra). - Mitigamos esto con un proceso de limpieza impulsado por eventos: los eventos de eliminación de usuario activan trabajos de limpieza asíncronos de Cassandra. Compensación 4: Entrega Al Menos Una Vez vs. Exactamente Una Vez Decisión: Elegimos semántica de entrega al menos una vez con desduplicación a nivel de aplicación. - La entrega exactamente una vez en sistemas distribuidos es extremadamente costosa y compleja (requiere transacciones distribuidas o las semánticas de entrega exactamente una vez de Kafka con una sobrecarga de rendimiento significativa). - Al menos una vez es más simple y más eficiente. Los duplicados de notificaciones se manejan en la capa de aplicación utilizando claves de idempotencia (notification_id verificado antes de la entrega). - El riesgo es que en escenarios de fallo raros, un usuario pueda recibir una notificación push duplicada. Esto es una molestia menor en comparación con el riesgo de notificaciones perdidas (como máximo una vez) o el costo de complejidad/rendimiento de exactamente una vez. ================================================================================ RESUMEN ================================================================================ Este diseño maneja 200M de notificaciones/día a través de tres canales con una latencia de entrega inferior a 2 segundos. La arquitectura impulsada por eventos con Kafka como sistema nervioso central proporciona durabilidad, desacoplamiento y manejo natural de la contrapresión. Cassandra proporciona almacenamiento de notificaciones escalable horizontalmente, mientras que la pasarela WebSocket permite la entrega in-app en tiempo real. El sistema está diseñado para una disponibilidad del 99.9% a través de despliegues multiaz, replicación en todas las capas y patrones de degradación elegante. Las compensaciones clave favorecen la disponibilidad, la escalabilidad y la simplicidad operativa sobre la consistencia estricta y las semánticas de entrega exactamente una vez, que son opciones apropiadas para un sistema de notificaciones donde la inconsistencia ocasional o los duplicados raros son aceptables.

Diseño de alto nivel 1. Arquitectura central Un buen diseño es impulsado por eventos, consciente del canal y prioriza la durabilidad. Flujo principal - Servicios de productos como Me gusta, Comentarios, Seguir, Menciones, Mensajes publican eventos que merecen notificación. - La puerta de enlace de API o la API interna de ingesta de eventos reciben solicitudes directas si es necesario, pero la mayor parte del tráfico debe provenir de flujos de eventos internos. - El orquestador de notificaciones valida el evento, lo desduplica, expande los destinatarios, verifica las preferencias del usuario, crea un registro de notificación duradero y emite trabajos de entrega por canal. - La cola de mensajes / el bus de eventos almacenan temporalmente el trabajo para los trabajadores de canal descendentes. - Los trabajadores de canal manejan la entrega push, por correo electrónico y dentro de la aplicación de forma independiente. - El servicio de estado de entrega actualiza el estado de la notificación y reintenta cuando es necesario. - Las API de lectura sirven la bandeja de entrada de notificaciones y los recuentos no leídos a los clientes. - La puerta de enlace WebSocket / SSE puede enviar actualizaciones dentro de la aplicación en tiempo real a los usuarios en línea. Componentes clave - Puerta de enlace de API - Autenticación, limitación de velocidad, enrutamiento, observabilidad. - Se utiliza para las API de lectura del cliente y las API de administración. - Bus de eventos / Flujo de ingesta - Registro duradero estilo Kafka / Pulsar. - Productores: grafo social, contenido, mensajería, moderación, etc. - Tópico particionado por user_id del destinatario para preservar el orden por usuario cuando sea útil. - Orquestador de notificaciones - Servicio sin estado que consume eventos. - Responsabilidades: - validar esquema - verificación de idempotencia usando event_id o clave de deduplicación - decisión de difusión - búsqueda de preferencias - selección de plantilla - clasificación de prioridad - persistencia del registro de notificación canónico - encolar tareas de entrega por canal - Escribe primero, luego programa la entrega, para que no se pierdan datos. - Servicio de preferencias - Devuelve la configuración del canal a nivel de usuario, horas de silencio, tokens de dispositivo, idioma, estado de verificación de correo electrónico. - Respaldado por una tienda de preferencias de usuario fuertemente consistente más caché. - Almacén de notificaciones - Almacén duradero canónico para metadatos de notificación y registros de la bandeja de entrada del usuario. - Optimizado para escrituras y lecturas recientes. - Cola de entrega - Colas/tópicos separados por canal: push, correo electrónico, dentro de la aplicación. - Permite diferentes políticas de reintento y rendimiento. - Trabajador Push - Se integra con APNS/FCM. - Maneja la invalidación de tokens, cargas útiles específicas de la plataforma, retroceso exponencial. - Trabajador de correo electrónico - Se integra con el proveedor de correo electrónico. - Menor prioridad que push/dentro de la aplicación para la mayoría de los eventos sociales. - Rastrea rebotes, quejas, lista de supresión. - Trabajador de entrega dentro de la aplicación - Escribe en el almacén de la bandeja de entrada y, si el usuario está en línea, envía a través de WebSocket/SSE. - Si está fuera de línea, la notificación permanece disponible a través de la extracción de la API de la bandeja de entrada. - Puerta de enlace en tiempo real - Mantiene conexiones de cliente persistentes para usuarios activos. - Se suscribe a eventos de entrega dentro de la aplicación y envía en menos de 2 segundos. - API de lectura / Servicio de bandeja de entrada - Listar notificaciones, marcar como leído, recuento no leído, paginación. - Lee del almacén de la bandeja de entrada de notificaciones y la caché. - Procesador de reintentos / Cola de mensajes fallidos (DLQ) - Reintenta fallos transitorios. - DLQ para mensajes venenosos o fallos permanentes. - Soporta repetición. - Pila de observabilidad - Métricas: latencia de encolado a entrega, tasa de éxito por canal, recuentos de reintentos, retraso de la cola. - Registros y rastreo distribuido. - Alertas sobre incumplimientos de SLA. Secuencia de interacción - Un servicio de comentarios emite el evento CommentCreated. - El bus de eventos almacena el evento de forma duradera. - El orquestador de notificaciones consume el evento, determina el usuario destinatario, verifica las preferencias, crea una fila de notificación y emite trabajos a: - cola dentro de la aplicación - cola push si está habilitada y es lo suficientemente urgente - cola de correo electrónico si está configurada - El trabajador dentro de la aplicación almacena el elemento de la bandeja de entrada y envía a través de WebSocket si el usuario está en línea. - El trabajador push envía a FCM/APNS. - Se escriben las confirmaciones/actualizaciones de estado de entrega. - El usuario puede obtener la bandeja de entrada completa a través de la API de lectura. Estimación de rendimiento - 10M DAU × 20 notificaciones/día = 200M notificaciones/día. - Rendimiento promedio = aproximadamente 2315 notificaciones/segundo. - Los sistemas reales tienen picos, por lo que el diseño debe tener al menos 10 veces más margen de pico: 20k a 30k creaciones de notificaciones/segundo, con la difusión por canal haciendo que la entrega descendente sea mayor. - Esta escala es muy manejable con colas particionadas y trabajadores sin estado escalados horizontalmente. 2. Esquema de base de datos Usar un modelo dividido: - almacén duradero transaccional para registros de notificación canónicos y preferencias - caché para lecturas frecuentes - almacén de búsqueda/índice opcional para consultas avanzadas de la bandeja de entrada Esquema básico users_notification_preferences - user_id PK - push_enabled booleano - email_enabled booleano - in_app_enabled booleano - quiet_hours_start - quiet_hours_end - timezone - locale - email_address - email_verified booleano - push_tokens json / tabla separada - notification_type_settings json o tabla hija normalizada - updated_at user_device_tokens - token_id PK - user_id - platform - device_token - app_version - last_seen_at - is_active - unique(device_token) - index(user_id) notifications - notification_id PK - recipient_user_id - actor_user_id nullable - type - object_type - object_id - dedupe_key - title - body - payload json - priority - created_at - expire_at nullable - aggregation_key nullable - source_event_id unique - índices: - (recipient_user_id, created_at desc) - (recipient_user_id, notification_id) - unique(source_event_id) o unique(dedupe_key) notification_deliveries - delivery_id PK - notification_id - channel enum(push, email, in_app) - status enum(pending, sent, delivered, failed, suppressed) - provider_message_id nullable - attempt_count - last_attempt_at - next_retry_at nullable - failure_reason nullable - delivered_at nullable - índices: - (notification_id) - (channel, status, next_retry_at) notification_reads - notification_id - user_id - read_at - primary key(notification_id, user_id) - index(user_id, read_at) Optimización opcional: tabla user_inbox - user_id - notification_id - created_at - read_state - primary key(user_id, created_at, notification_id) Esta puede ser la tabla principal en un almacén de columnas anchas para la recuperación de la bandeja de entrada. Opciones de almacenamiento - Preferencias: base de datos relacional o almacén de claves-valores fuertemente consistente. - Notificaciones/bandeja de entrada: Cassandra/DynamoDB/Bigtable-estilo de columna ancha KV es atractivo porque el patrón de acceso es principalmente por user_id y lecturas recientes ordenadas por tiempo, con un volumen de escritura muy alto. - Auditoría/estado de entrega: almacén relacional o KV dependiendo de las necesidades de informes. - Caché: Redis para recuentos no leídos y páginas recientes de la bandeja de entrada. 3. Estrategia de escalado Escalado horizontal - Todos los servicios sin estado se escalan horizontalmente automáticamente: orquestador, trabajadores de canal, API de lectura, puertas de enlace WebSocket. - Particionar los tópicos de eventos por recipient_user_id para distribuir la carga de manera uniforme y preservar el orden por usuario. - Separar las colas por canal y prioridad para que el back-end de correo electrónico no afecte la latencia de push. Escalado de datos - Fragmentar los datos de notificación por user_id. - Usar agrupación por tiempo si es necesario para usuarios muy grandes, por ejemplo, clave de partición (user_id, mes). - TTL para notificaciones antiguas de bajo valor después de la política de retención si el negocio lo permite, mientras se archiva en almacenamiento de objetos económico. - Caché de recuentos no leídos y las últimas N notificaciones. Modelado de tráfico - Carriles de prioridad: - alta: menciones directas, mensajes, alertas de seguridad - media: comentarios, me gusta - baja: actividad digerible o artículos promocionales - Durante los picos, proteger primero las notificaciones de alta prioridad. - Agrupar la generación de correos electrónicos de baja prioridad. Estrategia de difusión (Fanout) - Preferir difusión al escribir (fanout-on-write) para la bandeja de entrada por usuario y canales en tiempo real porque el objetivo de latencia es inferior a 2 segundos. - Para eventos de difusión extremadamente grandes, como publicaciones de celebridades a millones de personas, usar manejo híbrido: - crear un evento general una vez - difundir asincrónicamente en lotes - degradar potencialmente canales no críticos a entrega por resumen o retrasada Esto evita estampidas. Escalado geográfico - Activo-activo multirregión para API de ingesta y entrega. - Mantener la afinidad del usuario con la región de origen cuando sea posible para reducir las escrituras entre regiones. - Replicar metadatos críticos globalmente. - Los proveedores de canal se llaman desde la región más cercana. Planificación de capacidad - 200M/día de notificaciones canónicas. - Si cada una crea de 2 a 3 intentos por canal en promedio, los registros de entrega descendentes pueden ser de 400M a 600M/día. - Usar particiones de cola dimensionadas para el rendimiento pico, por ejemplo, docenas a cientos de particiones dependiendo del broker. - Puerta de enlace WebSocket dimensionada por usuarios en línea concurrentes, no por DAU. 4. Fiabilidad y tolerancia a fallos Objetivo de disponibilidad: 99.9% - Despliegue Multi-AZ para cada nivel. - Sin punto único de fallo. - Balanceadores de carga entre instancias. - Broker y base de datos administrados con replicación. Sin pérdida de datos de notificación - Persistir la notificación canónica antes de los intentos de entrega. - Usar registro/cola duradero con factor de replicación >= 3. - Consumidores idempotentes y reintentos del productor. - Patrón Outbox para servicios productores ascendentes si emiten eventos de notificación desde operaciones transaccionales. - Ejemplo: una escritura de comentario y un evento de notificación se vinculan usando una transacción de base de datos + outbox para evitar eventos perdidos. - Capacidad de repetición desde el registro de eventos y DLQ. Manejo de fallos - Entrega al menos una vez (at-least-once) internamente, con desduplicación en las capas de orquestador y canal. - Reintentos con retroceso exponencial para fallos transitorios del proveedor. - DLQ para tareas mal formadas o que fallan repetidamente. - Circuit breakers alrededor de APNS/FCM/proveedores de correo electrónico. - Comportamiento de respaldo: - si el proveedor push está degradado, aún así almacenar la notificación dentro de la aplicación - si el proveedor de correo electrónico está caído, mantener en cola y reintentar más tarde Consistencia e integridad de datos - source_event_id o dedupe_key únicos evitan la creación de notificaciones duplicadas. - La máquina de estados de entrega evita transiciones inválidas. - Consistencia fuerte para actualizaciones de preferencias si se requiere efecto inmediato, de lo contrario, se acepta una posible inconsistencia temporal (bounded staleness) a través de la invalidación de caché. Recuperación ante desastres - Metadatos replicados entre regiones y copias de seguridad. - Instantáneas periódicas más WAL/binlog o retención de flujo. - RPO definido cerca de cero usando registro duradero replicado. - RTO minimizado con infraestructura como código y diseño de standby caliente/activo-activo. Fiabilidad operativa - SLOs para latencia de encolado a persistencia y de persistencia a entrega. - Alarmas de retraso de cola. - Sondas sintéticas para rutas push/email/in-app. - Controles de contrapresión cuando los proveedores descendentes limitan la velocidad. - Límites de velocidad por inquilino/tipo de evento para contener abusos. 5. Compromisos clave Compromiso 1: Entrega al menos una vez (at-least-once) vs entrega exactamente una vez (exactly-once) - Elegido: al menos una vez con idempotencia. - Por qué: exactamente una vez entre brokers, bases de datos y proveedores externos como APNS/FCM/correo electrónico es costoso y a menudo poco práctico. - Impacto: son posibles intentos duplicados ocasionales, pero las claves de deduplicación y las escrituras idempotentes hacen que los duplicados visibles para el usuario sean raros. - Beneficio: mucho más simple y confiable ante fallos. Compromiso 2: Almacén de columna ancha/KV vs base de datos relacional para la bandeja de entrada de notificaciones - Elegido: almacén de columna ancha o estilo Dynamo para la bandeja de entrada, relacional para preferencias y algunos metadatos. - Por qué: la carga de trabajo de notificaciones tiene muchas escrituras, es pesada en adiciones y lee principalmente por usuario y por fecha reciente. - Impacto: menor capacidad de consulta ad hoc y modelado de datos más cuidadoso. - Beneficio: escala horizontal mucho mejor y rendimiento predecible. Compromiso 3: Difusión al escribir (fanout-on-write) vs difusión al leer (fanout-on-read) - Elegido: principalmente difusión al escribir. - Por qué: requisito de latencia inferior a 2 segundos y necesidad de inmediatez push/dentro de la aplicación. - Impacto: más amplificación de escritura, especialmente para eventos de alta difusión. - Mitigación: enfoque híbrido para casos de mega-difusión. Compromiso 4: Entrega en tiempo real push vs bandeja de entrada solo por consulta (pull) - Elegido: híbrido. - Por qué: push/WebSocket proporciona baja latencia para usuarios activos, la API de consulta proporciona resiliencia para usuarios fuera de línea. - Impacto: mayor complejidad del sistema porque se requieren tanto el estado de la conexión como la persistencia de la bandeja de entrada. - Beneficio: la mejor experiencia de usuario y fiabilidad. Resumen de la arquitectura final sugerida - Ingerir eventos a través de un bus de eventos duradero. - Utilizar un Orquestador de Notificaciones sin estado para desduplicar, verificar preferencias, persistir registros de notificación y publicar trabajos específicos del canal. - Almacenar los datos de la bandeja de entrada en un almacén particionado por usuario y escalable horizontalmente, con un almacén KV relacional o fuertemente consistente para las preferencias. - Entregar a través de trabajadores dedicados de push, correo electrónico y dentro de la aplicación. - Utilizar WebSocket/SSE para actualizaciones en tiempo real dentro de la aplicación y API de lectura normales para la recuperación de la bandeja de entrada. - Garantizar la fiabilidad a través de despliegue Multi-AZ, colas replicadas, escrituras priorizando la durabilidad, idempotencia, reintentos, DLQs, repetición y recuperación ante desastres entre regiones. Este diseño soporta cómodamente 10M DAU y 200M notificaciones/día, al tiempo que cumple con una entrega inferior a 2 segundos para la mayoría de las notificaciones en tiempo real y mantiene un 99.9% de disponibilidad sin pérdida de datos.