Diseñar un sistema de notificaciones en tiempo real escalable

Diseño: Sistema de Notificaciones Escalable en Tiempo Real 1. ARQUITECTURA GENERAL El sistema se compone de varias capas distintas que trabajan juntas para ingerir eventos, enrutarlos y enviarlos a los clientes conectados con una latencia mínima. Capa de Cliente: Los clientes móviles y web mantienen conexiones WebSocket persistentes a un conjunto de servidores Gateway de Conexión. Cada cliente se autentica al conectarse y registra su ID de usuario con la puerta de enlace. API Gateway / Balanceador de Carga: Un balanceador de carga de Capa 7 (por ejemplo, AWS ALB o NGINX) se sitúa delante de los Gateways de Conexión. Enruta las nuevas solicitudes de actualización de WebSocket utilizando un hash consistente en el ID de usuario para que las reconexiones tiendan a aterrizar en el mismo nodo de puerta de enlace, reduciendo el cambio de estado. También expone un punto final REST para que los servicios internos publiquen eventos. Servicio de Publicación de Eventos: Los servicios de la plataforma interna (como el servicio de notificaciones, el servicio de comentarios, el servicio de amigos) publican eventos en un bróker de mensajes central. Llaman a una API de publicación delgada que valida la carga útil, la enriquece con metadatos (marca de tiempo, ID de notificación) y la escribe en el bróker. Bróker de Mensajes (Kafka): Los eventos se escriben en temas de Kafka particionados por ID de usuario. Esto garantiza la entrega ordenada por usuario y permite la escalabilidad horizontal de los consumidores. El registro duradero de Kafka también proporciona la capacidad de repetición necesaria para las garantías de entrega de "al menos una vez". Servicio de Fanout de Notificaciones: Un grupo de trabajadores consumidores sin estado lee de Kafka. Para cada evento, el trabajador busca las preferencias de suscripción del usuario de destino en una caché rápida (Redis), determina qué usuarios deben recibir la notificación y luego enruta el mensaje al Gateway de Conexión correcto. Para eventos de alto fanout (por ejemplo, una publicación de una celebridad), se activa un trabajo de fanout asíncrono separado para evitar bloquear la ruta principal. Gateway de Conexión (Servidores WebSocket): Estos son servidores con estado que mantienen las conexiones WebSocket abiertas. Cada puerta de enlace mantiene un mapa en memoria de ID de usuario a manejador de conexión. Cuando llega una notificación enrutada (a través de un canal interno de pub/sub como Redis Pub/Sub o una llamada gRPC directa), la puerta de enlace la envía a través de la conexión WebSocket apropiada. Si el usuario no está conectado, la puerta de enlace descarta el envío y depende de la capa de persistencia para la entrega posterior. Servicio de Presencia y Enrutamiento: Un clúster de Redis almacena un mapeo de ID de usuario a ID de nodo de puerta de enlace con una TTL corta, actualizado por latidos. El Servicio de Fanout consulta esto para saber a qué puerta de enlace enrutar una notificación. Si no existe ninguna entrada, el usuario está desconectado. Almacenamiento de Notificaciones (Cassandra): Todas las notificaciones generadas se escriben en Cassandra, indexadas por ID de usuario y ordenadas por marca de tiempo. Esto cumple dos propósitos: potencia la interfaz de usuario de la bandeja de entrada de notificaciones (los usuarios pueden desplazarse por notificaciones pasadas) y permite la entrega de "al menos una vez": cuando un usuario se conecta, el cliente recupera las notificaciones no leídas de este almacén. Acuse de Recibo de Entrega: Los clientes envían un mensaje ACK a través de WebSocket después de recibir una notificación. La puerta de enlace escribe este ACK en Kafka, y un consumidor marca la notificación como entregada en Cassandra. Las notificaciones no acusadas que tengan más de un umbral se vuelven a poner en cola para su entrega. 2. OPCIONES TECNOLÓGICAS Y RAZONAMIENTO WebSockets sobre Long Polling o SSE: WebSockets proporciona conexiones persistentes full-duplex y de baja sobrecarga. El Long Polling desperdicia recursos del servidor con apretones de manos HTTP repetidos y añade latencia. Server-Sent Events (SSE) son unidireccionales y menos adecuadas para el flujo de ACK. Con 1 millón de conexiones concurrentes, WebSockets es la opción más eficiente en cuanto a recursos. Cada conexión consume aproximadamente 10–50 KB de memoria, lo que hace que 1 millón de conexiones sean factibles en un conjunto de puertas de enlace de tamaño moderado. Kafka sobre RabbitMQ: Se elige Kafka por su alto rendimiento (millones de mensajes por segundo), almacenamiento de registro duradero, semántica de grupo de consumidores y la capacidad de reproducir mensajes. RabbitMQ es un buen bróker para colas de tareas, pero su modelo de mensajes es menos adecuado para los patrones de fanout y repetición necesarios aquí. La partición de Kafka por ID de usuario también paraleliza naturalmente el consumo. Con 10.000 notificaciones por segundo, Kafka maneja esto con un margen considerable. Redis para Presencia y Pub/Sub: Redis proporciona lecturas de sub-milisegundos para la consulta de presencia (ID de usuario → nodo de puerta de enlace). Redis Pub/Sub o Redis Streams se pueden usar para el canal interno entre el Servicio de Fanout y los Gateways de Conexión, agregando una latencia mínima a la ruta de entrega. Cassandra sobre MySQL/PostgreSQL: El historial de notificaciones es una carga de trabajo intensiva en escritura, de series temporales con alta cardinalidad (una partición por usuario). El modelo de columnas anchas de Cassandra, la consistencia ajustable y la escalabilidad horizontal lineal lo hacen ideal. Una base de datos relacional requeriría fragmentación compleja y tendría dificultades con el rendimiento de escritura. La consistencia eventual de Cassandra es aceptable aquí, ya que el historial de notificaciones no es un registro transaccional. Trabajadores de Fanout sin Estado: Mantener los trabajadores de fanout sin estado les permite escalar horizontalmente simplemente agregando más instancias de consumidores de Kafka dentro del grupo de consumidores. 3. CÓMO EL DISEÑO CUMPLE CADA REQUISITO Escalabilidad (1M de usuarios concurrentes, 10K de notificaciones/segundo): Los Gateways de Conexión son escalables horizontalmente. Un solo servidor moderno puede manejar 50.000–100.000 conexiones WebSocket, por lo que 10–20 nodos de puerta de enlace manejan 1 millón de usuarios. El balanceador de carga distribuye las nuevas conexiones. Las particiones de Kafka escalan los trabajadores de fanout. Cassandra escala las escrituras linealmente con los nodos. Redis Cluster fragmenta los datos de presencia. Ningún componente individual es un cuello de botella. Latencia (P99 < 200 ms): La ruta crítica es: evento publicado → escritura en Kafka (~5 ms) → trabajador de fanout consume y busca presencia en Redis (~5 ms) → enruta a la puerta de enlace a través de Redis Pub/Sub o gRPC (~5 ms) → la puerta de enlace envía a través de WebSocket (~10 ms de red). El total está muy por debajo de los 50 ms en el caso mediano. El presupuesto de P99 de 200 ms acomoda el retraso del consumidor de Kafka bajo carga máxima y la fluctuación de la red. Mantener la lógica del trabajador de fanout simple y las búsquedas de Redis cacheadas asegura que la ruta principal se mantenga rápida. Fiabilidad (entrega "al menos una vez"): Las notificaciones se persisten en Cassandra antes o al mismo tiempo que el intento de envío. Si el envío de WebSocket falla o el cliente no acusa recibo, la notificación permanece en el estado no leído en Cassandra. Al reconectarse, el cliente recupera las notificaciones no leídas. El commit del offset del consumidor de Kafka solo se realiza después de que el trabajador de fanout haya enrutado con éxito el mensaje, asegurando que ningún evento se pierda silenciosamente. Esto proporciona semántica de "al menos una vez" de extremo a extremo. Disponibilidad (99.95% de tiempo de actividad): Todos los componentes se implementan en múltiples zonas de disponibilidad. El balanceador de carga, los brókers de Kafka, los nodos de Redis Cluster, los nodos de Cassandra y los trabajadores de fanout se ejecutan con redundancia N+1 o N+2. Las fallas de los nodos de la puerta de enlace hacen que los clientes se reconecten (lógica de reconexión de WebSocket con retroceso exponencial) y aterricen en un nodo saludable en segundos. El factor de replicación de Kafka de 3 garantiza que las fallas de los brókers no causen pérdida de datos. El factor de replicación de Cassandra de 3 con lecturas/escrituras de quorum tolera fallas de nodos. Esta arquitectura logra cómodamente un tiempo de actividad del 99.95%. 4. COMPENSACIONES Complejidad vs. Simplicidad: Este diseño tiene muchas partes móviles: Kafka, Redis, Cassandra, puertas de enlace WebSocket, trabajadores de fanout, servicio de presencia. Esto es significativamente más complejo de operar que un sistema de sondeo simple o una configuración de bróker único. La compensación se justifica por los requisitos de escala, pero exige una práctica DevOps madura, buena observabilidad (rastreo distribuido, métricas por componente) y experiencia de guardia. "Al menos una vez" vs. "Exactamente una vez": La entrega "exactamente una vez" requeriría transacciones distribuidas entre Kafka, Cassandra y la puerta de enlace, lo que añadiría una latencia y complejidad significativas. En su lugar, se elige "al menos una vez", lo que significa que un usuario podría ver ocasionalmente una notificación duplicada. Esto se maneja en el lado del cliente deduplicando por ID de notificación. Para una notificación de redes sociales (un me gusta o un comentario), un duplicado es una molestia menor en la experiencia del usuario, no un fallo crítico: una compensación aceptable. Puertas de enlace con Estado: Las puertas de enlace WebSocket tienen estado (mantienen conexiones activas). Esto hace que las implementaciones graduales y la recuperación de fallos sean un poco más complejas que un servicio completamente sin estado. Los clientes deben implementar lógica de reconexión. La compensación es que las puertas de enlace con estado son necesarias para el envío en tiempo real; no hay forma de enviar a un cliente sin una conexión persistente. Fanout en Tiempo de Lectura vs. Escritura: Este diseño realiza el fanout en el momento de la escritura (el trabajador de fanout envía a la puerta de enlace de cada destinatario inmediatamente). Para usuarios con millones de seguidores, esto crea un problema de ruta principal (la publicación de una celebridad desencadena millones de operaciones de fanout). La mitigación es usar una cola de trabajos de fanout separada para cuentas por encima de un umbral de seguidores, procesándolas de forma asíncrona. La compensación es que los usuarios con muchos seguidores pueden experimentar una latencia de notificación ligeramente mayor, lo cual es generalmente aceptable. Fiabilidad de Redis Pub/Sub: Redis Pub/Sub no persiste mensajes. Si una puerta de enlace se desconecta brevemente de Redis cuando se publica un mensaje, pierde ese mensaje. Esto se mitiga con la capa de persistencia de Cassandra: el cliente recuperará la notificación al reconectarse, pero significa que el envío en tiempo real es un "best-effort", con el almacén persistente como red de seguridad. Usar Redis Streams en lugar de Pub/Sub añadiría persistencia a costa de una complejidad ligeramente mayor. Costo: Ejecutar Kafka, Redis Cluster, Cassandra y un gran conjunto de puertas de enlace WebSocket es costoso. Una plataforma más pequeña podría usar un servicio administrado como AWS SNS/SQS o Firebase Cloud Messaging para reducir la carga operativa. A la escala descrita (1 millón de usuarios concurrentes), el control y el rendimiento de una pila personalizada justifican el costo.

Resumen de alto nivel Propongo una plataforma de notificaciones en tiempo real, escalable horizontalmente y de baja latencia, construida en torno a: (1) infraestructura de borde/gateway para aceptar eventos y conexiones de clientes, (2) una columna vertebral de publicación/suscripción duradera para enrutar eventos a los suscriptores interesados, (3) gestores de conexión / trabajadores WebSocket que mantienen conexiones de clientes activas y realizan la distribución (fan-out), y (4) un almacén de presencia rápido y un almacén de notificaciones duradero para la fiabilidad y la entrega sin conexión. El sistema utiliza particionamiento y replicación para cumplir los objetivos de rendimiento y disponibilidad, con instrumentación de extremo a extremo, backpressure e idempotencia para garantizar la entrega al menos una vez y baja latencia. 1) Arquitectura general (componentes y flujo de solicitudes) Componentes principales - API Gateway / Ingress: Acepta la publicación de eventos (desde servicios internos) y las actualizaciones de conexión de clientes. Expone puntos finales REST/gRPC para los publicadores de eventos y maneja la autenticación y la limitación de velocidad. Desplegado detrás de LBs globales y puntos finales por región. - Capa de Conexión (WebSocket / GRPC streams): Una flota de servidores de conexión sin estado (WebSocket/HTTP2 o gRPC) que mantienen conexiones persistentes con los clientes. Realizan un enrutamiento ligero y el manejo de acuses de recibo, y reenvían los cambios de suscripción al almacén de presencia. - Almacén de Presencia y Enrutamiento: Un almacén clave-valor de baja latencia (cluster Redis) que rastrea qué servidor(es) de conexión alojan actualmente a cada usuario en línea y a qué temas se suscriben. Se utiliza para enrutar notificaciones al trabajador de conexión correcto. - Columna vertebral de Publicación/Suscripción: Un bus de mensajes duradero y particionado (Kafka o Apache Pulsar) utilizado para distribuir eventos desde los publicadores a los trabajadores de notificaciones. Los temas se particionan por claves lógicas (ID de usuario, ID de tema) para garantizar el procesamiento ordenado por clave y un rendimiento escalable. - Servicio de Notificaciones / Pool de Trabajadores: Consumidores del tema de publicación/suscripción que realizan el enriquecimiento, filtrado y enrutamiento de entrega. Los trabajadores consultan el almacén de presencia para encontrar los servidores de conexión de destino y envían tareas de entrega a rutas de entrega rápidas. - Capa de Entrega / Motor de Distribución (Fan-out Engine): Los servidores de conexión reciben solicitudes de entrega (directamente o a través de RPC rápido) y envían notificaciones a través de la conexión persistente al cliente. Manejan el control de flujo por conexión, el lotes y los ACKs de los clientes. - Almacén de Notificaciones Duradero (NoSQL): Un almacén replicado optimizado para escritura (por ejemplo, Cassandra / DynamoDB) para persistir notificaciones para usuarios sin conexión, reintentos y auditoría. Almacena cargas útiles de notificaciones, intentos de entrega, marcas de tiempo, TTLs. - Almacén de Deduplicación e Idempotencia: Pequeño almacén clave-valor (Redis o RocksDB) para registrar IDs de mensajes recientes para la deduplicación cuando las semánticas de entrega al menos una vez causan duplicados. - Plano de Control y Monitorización: Métricas, trazabilidad, SLO/alertas, disyuntores y limitación. Flujos típicos - Flujo de publicación (productor de eventos -> usuario): 1) El publicador envía el evento a la API Gateway (REST/gRPC). 2) La pasarela escribe el mensaje en el tema de Publicación/Suscripción (particionado por tema/ID de usuario de destino). 3) Los trabajadores de notificaciones consumen eventos, enriquecen y resuelven listas de suscripción (o consultan la base de datos de suscripciones), consultan el almacén de presencia para encontrar destinatarios en línea y, para cada conexión en línea, envían a los servidores de conexión apropiados. 4) Los servidores de conexión envían a través del stream WebSocket/gRPC al cliente y esperan un ACK ligero. 5) Si el usuario está sin conexión (ausencia de presencia), se escribe en el Almacén de Notificaciones duradero para la recuperación sin conexión. - Flujo de suscripción: Los clientes envían mensajes de suscripción/cancelación de suscripción a través de su conexión persistente. El servidor de conexión actualiza el almacén de presencia de forma atómica para que el enrutamiento del trabajador vea las suscripciones actualizadas rápidamente. - Recuperación y repetición: La publicación/suscripción duradera y el Almacén de Notificaciones permiten la repetición de eventos perdidos; los servidores de conexión re-registran la presencia al reconectarse. 2) Opciones tecnológicas y justificación - Conexión de cliente: WebSockets o streams HTTP/2 (gRPC) - Elección: WebSockets para una amplia compatibilidad con clientes (móviles/web). Considerar streams gRPC HTTP/2 para aplicaciones internas/móviles que lo soporten. Ambos mantienen conexiones TCP/TLS persistentes para cumplir con una latencia <200ms. - Razón: El sondeo (polling) es demasiado lento e ineficiente. El sondeo largo aumenta la latencia y el uso de recursos. WebSockets proporciona push, bajo RTT y la capacidad de entregar mensajes binarios con poca sobrecarga. - Columna vertebral de Publicación/Suscripción: Apache Kafka o Apache Pulsar - Elección: Kafka (gestionado como Confluent Cloud o autoalojado) o Pulsar si las necesidades de multi-tenencia y replicación geográfica dominan. - Razón: Ambos proporcionan mensajería duradera, particionada y de alto rendimiento. Kafka tiene herramientas maduras, un rendimiento sólido, latencia predecible y soporte para semánticas de entrega exactamente una vez en los publicadores. El particionamiento permite escalar a 10k msg/s fácilmente. Pulsar ofrece replicación geo-incorporada si se requiere multi-región. - Almacén de presencia y enrutamiento: Redis Cluster (en memoria) con replicación - Razón: Lecturas/escrituras por debajo de 1ms para mapear usuario -> servidores de conexión, suscripciones y metadatos de conexión. Redis soporta clustering, persistencia (AOF/RDB) y búsquedas rápidas necesarias para enrutar eventos dentro del presupuesto de 200ms. - Almacén de notificaciones persistente: Cassandra / DynamoDB (NoSQL) - Elección: Cassandra o un almacén clave-valor similar a DynamoDB. - Razón: Alto rendimiento de escritura, escalabilidad lineal y TTLs configurables, ideal para almacenar muchas escrituras por segundo y servir lecturas sin conexión. Los sistemas SQL tienen dificultades a esta escala de escrituras y complejidad de fragmentación horizontal. - Servidores de conexión y comunicación de trabajadores: gRPC/RPC interno + protobuf - Razón: Mensajes binarios de baja sobrecarga, soporte de backpressure, tipado fuerte y alto rendimiento. - Balanceo de carga y enrutamiento: Balanceadores de carga L4 (TCP) para WebSockets + LB L7 para APIs REST. Usar enrutamiento pegajoso (sticky routing) mediante hashing consistente o afinidad de sesión para dirigir las reconexiones a la misma región. - Formato de carga útil del cliente: Binario compacto (protobuf/flatbuffers) para cargas útiles más pequeñas y serialización más rápida. 3) Cómo el diseño cumple los requisitos no funcionales - Escalabilidad (1M de usuarios concurrentes, 10k notif/s pico) - Servidores de conexión sin estado: Escalado horizontal; cada servidor maneja N conexiones WebSocket concurrentes. Con máquinas modernas (por ejemplo, 100k sockets por máquina con ajuste adecuado), unas pocas docenas/cientos de servidores manejan 1M de sockets concurrentes. El grupo de escalado automático y la orquestación de contenedores gestionan la capacidad. - Publicación/suscripción particionada (Kafka): Escalar publicadores y consumidores añadiendo particiones/trabajadores. El particionamiento por ID de usuario de destino o tema garantiza una distribución uniforme de la carga. 10k msg/s es modesto para clústeres de Kafka dimensionados adecuadamente (docenas de brokers). - Almacén de presencia fragmentado: Redis Cluster fragmenta el espacio de usuarios para que las búsquedas sigan siendo O(1) y escalen. - Almacén duradero particionado: Cassandra escala linealmente añadiendo nodos para escrituras y lecturas. - Latencia (99% dentro de 200ms) - Las conexiones persistentes eliminan la sobrecarga del handshake TCP. Una vez establecidas, el push desde la publicación del evento al cliente es: API Gateway -> Anexión a Kafka (sub-ms-10s ms dependiendo del ajuste) -> consumo del trabajador -> búsqueda de presencia (sub-ms) -> RPC al servidor de conexión -> push sobre WebSocket (sub-ms a pocos ms). Con una ubicación cuidadosa (desplegar trabajadores y servidores de conexión en la misma región/zona), la latencia de red sigue siendo pequeña. Utilizar lotes ajustados para una entrega casi instantánea (evitar retrasos en el lotes) y ajustar la configuración del consumidor de Kafka (bajo linger.ms) para mantener baja la latencia de extremo a extremo. - Despliegue en borde/regional: Colocar los servidores de conexión cerca de los clientes (a nivel de región) para minimizar la latencia de la última milla. - Utilizar serialización binaria y cargas útiles pequeñas para reducir el tiempo de serialización/red. - Fiabilidad (entrega al menos una vez) - Escrituras duraderas: Los publicadores escriben eventos en Kafka (duradero), los trabajadores rastrean los offsets; los mensajes permanecen duraderos hasta que son confirmados por el procesamiento del consumidor. - Al menos una vez: Si la entrega falla (caída del servidor de conexión, red), el trabajador puede volver a encolar o reintentar porque la publicación/suscripción retiene los mensajes y el trabajador confirma los offsets solo después de la encolación/confirmación exitosa. Los clientes confirman la recepción, pero los ACKs solo confirman la aceptación del cliente; la persistencia del lado del servidor permite reintentos. - Deduplicación: Dado que la entrega al menos una vez puede producir duplicados, incluir IDs de mensajes únicos y cachés de deduplicación del lado del servidor para suprimir duplicados. - Almacén de Notificaciones Duradero: Cuando el usuario está sin conexión o cuando se requiere confirmación persistente, escribir la notificación en Cassandra antes de confirmar el evento para que pueda ser entregada más tarde. - Disponibilidad (99.95% de tiempo de actividad) - Despliegue multi-AZ y multi-región: Replicar componentes críticos. Usar Kafka con factor de replicación >2, Redis con maestro-réplica y failover, Cassandra con múltiples réplicas y consistencia configurable. - Frontends sin estado y escalado automático: Si falla algún servidor de conexión, los clientes se reconectan al siguiente servidor disponible. Usar comprobaciones de estado y failover rápido. - Degradación elegante: Si ocurre una sobrecarga de entrega, aceptar eventos y persistirlos para entrega posterior, en lugar de descartarlos. La limitación y el backpressure protegen el sistema. - Observabilidad y automatización: Reinicio automático, disyuntores y runbooks para intervención del operador. SLOs y alertas ajustados para mantener el 99.95% de disponibilidad. 4) Detalles operativos y optimizaciones - Claves de particionamiento y enrutamiento: Particionar la publicación/suscripción por ID de usuario para mensajes dirigidos a usuarios y por ID de tema para transmisiones de temas. Para distribuciones a muchos usuarios (por ejemplo, un post que le gusta a miles), realizar una distribución jerárquica: 1) determinar los destinatarios; 2) agrupar los destinatarios por servidor de conexión; 3) enviar el mensaje de entrega agrupado a cada servidor de conexión para evitar llamadas NRPC. - Estrategias de distribución (Fan-out) - Fan-out en escritura (push): Preferido para entrega en tiempo real en línea: los trabajadores envían solo a las conexiones en línea encontradas a través del almacén de presencia. - Fan-out en lectura (pull): Usar para distribuciones grandes sin conexión o para usuarios con conexión infrecuente; almacenar la notificación y permitir que los clientes la obtengan cuando estén en línea. - Lotes y coalescencia: Para eventos similares de alto volumen, combinar múltiples eventos en una notificación compacta cuando sea seguro (por ejemplo, "A 3 personas les gustó tu publicación") para reducir la carga y mejorar la experiencia del usuario. - Backpressure y suavizado: Si los servidores de conexión o el cliente no pueden aceptar mensajes, aplicar backpressure: ralentizar los consumidores, almacenar en búfer en el almacén duradero y reintentar. Implementar límites de velocidad por cliente. - Modelo ACK del cliente: Usar un ACK ligero para la recepción exitosa. Si el ACK no se recibe dentro del tiempo de espera, reintentar la entrega. Mantener contadores de intentos de entrega y enviar al almacén de mensajes fallidos después de N intentos. - Seguridad y privacidad: Autenticación de extremo a extremo en la pasarela, verificar el derecho del publicador a publicar; cifrar el transporte (TLS), y sanear las cargas útiles. 5) Compromisos y discusión - Complejidad vs Simplicidad - Compromiso: Un sistema de múltiples componentes basado en Kafka es operacionalmente más complejo que un servidor de push simple, pero necesario para la escala y la fiabilidad. El costo operativo y la complejidad de ingeniería aumentan (gestión de Kafka, cluster Redis, Cassandra), pero proporcionan durabilidad, repetición y control de distribución. - Al menos una vez vs Exactamente una vez - Elección: Se elige la entrega al menos una vez con deduplicación. La entrega exactamente una vez de extremo a extremo es muy costosa (coordinación entre servicios y clientes) y a menudo innecesaria para notificaciones donde los duplicados son tolerables. Las cachés de deduplicación y la idempotencia del lado del cliente proporcionan una mitigación práctica. - WebSockets vs gRPC HTTP/2 - Compromiso: WebSockets maximiza la compatibilidad pero requiere más ajuste de LB y conexión. gRPC ofrece mejor control de flujo y seguridad de tipos para los clientes que lo soportan. Soportar ambos añade complejidad pero proporciona la mejor cobertura. - Push en tiempo real vs Almacenamiento primero - Se prioriza el push primero para usuarios en línea para cumplir con la latencia. Sin embargo, el almacenamiento primero (persistir en la base de datos primero) añade durabilidad a costa de una latencia de escritura adicional. Logramos un equilibrio: escribir en Kafka (duradero) rápidamente, opcionalmente persistir en Cassandra dependiendo de la política de fiabilidad. - Consistencia eventual de la presencia de Redis - La presencia puede estar ligeramente desactualizada en casos extremos; una pequeña ventana de falsos negativos/positivos podría causar una única notificación perdida que se recuperará del almacén de notificaciones duradero. Este diseño favorece las búsquedas de presencia de baja latencia sobre los valores de presencia globales estrictamente síncronos. 6) Planificación de capacidad y números (cálculo rápido) - 1M de usuarios concurrentes: Si cada servidor de conexión maneja ~10k WebSockets concurrentes, se necesitan ~100 servidores de conexión. Añadir factor de seguridad (2x) para picos -> ~200 instancias en todas las regiones. - 10k notificaciones/s: Un clúster de Kafka con 10–50 particiones es suficiente dependiendo del tamaño del mensaje y la replicación; número objetivo de brokers alrededor de 5–10 con factor de replicación 3. Los grupos de consumidores escalan horizontalmente. - Almacenamiento: A 10k notif/s, ~864M de notificaciones por día (si cada mensaje se persiste) — usar TTLs y agregación para reducir el almacenamiento. Nodos de Cassandra dimensionados en consecuencia. 7) Modos de fallo y mitigaciones - Caída del servidor de conexión: Los clientes se reconectan a otros servidores; el almacén de presencia se actualiza al reconectar. Los mensajes en búfer en el trabajador se reintentan. Usar estrategias de reconexión pegajosa para reducir la rotación de estado. - Caída del broker de Kafka: La replicación de particiones garantiza que no haya pérdida de datos cuando el factor de replicación >=3 y se configura ISR. Monitorizar particiones sub-replicadas. - Failover de Redis: Usar Redis Cluster con réplicas y failover automatizado (Sentinel o servicios gestionados). Reconstruir la presencia desde los servidores de conexión en caso de un failover grande. - Distribuciones grandes (eventos virales): Usar distribución jerárquica y lotes; descargar a trabajadores en segundo plano y persistir notificaciones para entrega posterior si la entrega en tiempo real superaría la latencia. Conclusión Este diseño utiliza conexiones persistentes (WebSockets/gRPC), una publicación/suscripción particionada duradera (Kafka/Pulsar), un almacén de presencia de baja latencia (Redis) y un almacén NoSQL escalable (Cassandra/DynamoDB) para cumplir los objetivos de 1M de conexiones concurrentes, 10k notif/s, latencia del 99% <200ms, fiabilidad al menos una vez y 99.95% de disponibilidad. Las principales compensaciones son el aumento de la complejidad operativa y el manejo de duplicados. Con un particionamiento cuidadoso, replicación, monitorización y ajuste de cada componente (configuraciones de consumidor, lotes, backpressure), esta arquitectura escalará y proporcionará las notificaciones en tiempo real fiables y de baja latencia que la plataforma necesita.