Diseño de sistema: Servicio de notificaciones en tiempo real

SERVICIO DE NOTIFICACIÓN EN TIEMPO REAL — PLAN DE DISEÑO DEL SISTEMA

1. RESUMEN DE REQUISITOS Y ESTIMACIÓN DE CAPACIDAD

Matemáticas del tráfico:

• 100M DAU x 10 eventos/día = 1000 millones de eventos desencadenantes de notificaciones por día.
• Promedio = 1000 millones / 86 400 ≈ 11 600 eventos/segundo. Pico a 5x ≈ 58 000 eventos/segundo.
• Multiplicador de fan-out: la mayoría de los eventos (me gusta, comentario, seguir, DM) se dirigen exactamente a un destinatario, por lo que el fan-out es ~1:1. Sin embargo, los eventos de cuentas con muchos seguidores (una celebridad publicando) pueden distribuirse a millones de destinatarios; trátelos como una ruta separada de "fan-out masivo". Suponga una entrega pico efectiva de 80 000–100 000 notificaciones/segundo, incluidas las campañas masivas.
• Almacenamiento: historial de las últimas 100 notificaciones por usuario. Suponga ~400 bytes por fila -> 100 x 400 B = 40 KB/usuario -> 100M de usuarios ≈ 4 TB de historial activo, más un factor de replicación de 3 ≈ 12 TB. Se puede fragmentar trivialmente.
• Conexiones: suponga que entre el 20% y el 25% de los DAU están en línea simultáneamente en el pico ≈ 20–25M de conexiones WebSocket activas. Con ~100 000 conexiones por nodo de puerta de enlace (Linux ajustado, epoll), eso son 200–250 nodos más margen.

Objetivos no funcionales:

• Latencia p99 de extremo a extremo inferior a 2 segundos para usuarios en línea (medida desde la ingesta de eventos hasta la confirmación del cliente).
• Disponibilidad del 99,9 % = ~43 minutos de inactividad por mes.
• Entrega al menos una vez con deduplicación idempotente en el lado del cliente/servidor.

2. ARQUITECTURA DE ALTO NIVEL

El diseño es un pipeline impulsado por eventos con una clara división entre la ruta de ingesta (rápida, duradera, optimizada para escritura) y la ruta de entrega (específica del canal, reintentable).

Flujo:
Servicios productores (Servicio de Publicaciones, Servicio de Gráfico Social, Servicio de Comentarios, Servicio de Mensajería)
-> API/Puerta de Enlace de Notificaciones (gRPC + REST, autenticación, limitación de velocidad, validación de esquemas, clave de idempotencia)
-> Tópico de Kafka notification.events (particionado por recipient_user_id cuando se conoce, de lo contrario por actor_id)
-> Servicio de Fan-out (resuelve destinatarios, expande eventos de celebridades, aplica reglas de agregación)
-> Tópico de Kafka notification.deliveries (un mensaje por destinatario)
-> Servicio de Preferencias y Políticas (búsqueda en línea a través de caché: opt-ins de canal, horas de silencio, silenciar/bloquear, resumen vs. instantáneo)
-> El Enrutador/Distribuidor escribe en tópicos por canal:
deliver.websocket, deliver.mobile_push, deliver.web_push, deliver.email
-> Trabajadores de Canal:
Distribuidor WebSocket -> Búsqueda en el Registro de Conexiones -> nodo de Puerta de Enlace en Tiempo Real -> cliente
Trabajador de Push Móvil -> APNs (iOS) / FCM (Android)
Trabajador de Push Web -> Protocolo VAPID/Web Push a través de servicios de push del navegador
Trabajador de Correo Electrónico -> SES / SendGrid, con renderizado de plantillas y lotes de resúmenes
-> En paralelo, un consumidor de Escritor de Historial persiste cada entrega en la tienda de Historial de Notificaciones e incrementa los contadores de no leídos.

Transversales: Servicio de Plantillas, Registro de Dispositivos, Registro de Conexiones, Tienda de Deduplicación, Colas de Mensajes Fallidos (DLQ), pila de Observabilidad y un plano de Administración/Análisis que consume los mismos flujos de Kafka.

3. COMPONENTES CLAVE Y RESPONSABILIDADES

Puerta de Enlace de API de Notificaciones

• Punto de entrada único para productores internos (gRPC, esquemas protobuf en un registro) y para APIs de lectura de clientes (REST/GraphQL para historial, marcar como leído, preferencias).
• Responsabilidades: autenticación (servicio a servicio mTLS, JWT para clientes), limitación de velocidad/cuotas por inquilino y por productor, validación de solicitudes, aceptación de claves de idempotencia y adición duradera inmediata a Kafka. Devuelve 202 Accepted rápidamente; no realiza ningún trabajo de entrega en línea.

Ingesta de Eventos / Kafka

• Registro duradero y reproducible. notification.events con ~256 particiones, factor de replicación 3, min.insync.replicas=2, acks=all, retención de 7 días para recuperación de incidentes y reproducción.
• Proporciona contrapresión y almacenamiento en búfer naturales para el pico 5x, desacoplando a los productores de los proveedores externos lentos.

Servicio de Fan-out

• Resuelve un evento en una lista de destinatarios. Para eventos 1:1, es un pase directo. Para eventos 1:N (nueva publicación para seguidores, actividad de hilo grupal), pagina el Servicio de Gráfico Social y emite mensajes de destinatarios en lotes.
• Estrategia de fan-out híbrida: basada en push (escribir por destinatario) para cuentas normales; basada en pull/perezosa para cuentas por encima de un umbral de seguidores (por ejemplo, 1M+), donde se escribe un único "marcador de feed" y los destinatarios se materializan al leer. Esto evita que un evento de celebridad cree una tormenta de escritura de 50 millones de mensajes en la ruta activa.
• Limita la velocidad de las expansiones masivas a un tópico de Kafka separado de baja prioridad para que nunca agoten las notificaciones interactivas.
• Aplica agregación/coalescencia: "Alice y otras 24 personas le dieron me gusta a tu publicación" en lugar de 25 filas, utilizando una ventana deslizante corta (por ejemplo, 30–60 s) con clave (destinatario, post_id, tipo) en Redis.

Servicio de Preferencias y Políticas

• Almacena y sirve preferencias de canal por usuario, opt-ins a nivel de categoría, horas de silencio con zona horaria, configuraciones a nivel de dispositivo, listas de silenciar/bloquear y banderas de consentimiento legal (GDPR/CAN-SPAM).
• La ruta de lectura se almacena en caché en Redis con invalidación write-through; objetivo de búsqueda p99 inferior a 5 ms. Fuente de verdad en una tienda relacional.
• Aplica limitación de frecuencia (por ejemplo, máximo N pushes/hora por usuario) para proteger la experiencia del usuario y las cuotas del proveedor.

Enrutador / Distribuidor

• Mapea una entrega aprobada en elementos de trabajo específicos del canal. Decide "solo en la aplicación + WebSocket si está en línea; de lo contrario, push móvil" utilizando el Registro de Conexiones, y programa resúmenes de correo electrónico en lugar de envíos instantáneos cuando las preferencias lo indican.

Puerta de Enlace en Tiempo Real (capa WebSocket)

• Nivel con estado que mantiene conexiones WebSocket persistentes (fallback: Server-Sent Events, luego long polling).
• Al conectar: autenticar, registrar (user_id, device_id) -> gateway_node_id en el Registro de Conexiones (Redis Cluster, TTL + actualización de heartbeat), luego enviar cualquier historial pendiente.
• Al entregar: el distribuidor busca el nodo, envía a través de un flujo gRPC interno o un canal Kafka/Redis Pub/Sub por nodo; la puerta de enlace escribe en el socket y espera la confirmación del cliente.
• Heartbeats cada 30 s; los heartbeats perdidos eliminan la entrada del registro y las notificaciones futuras vuelven automáticamente al push móvil.

Trabajadores de Canal

• Trabajador de Push Móvil: lotes a APNs (HTTP/2 multiplexado, autenticación basada en tokens) y FCM. Maneja límites de concurrencia por proveedor, retroceso exponencial con jitter, y elimina tokens de dispositivo no válidos/no registrados del Registro de Dispositivos.
• Trabajador de Push Web: protocolo Web Push con claves VAPID y cifrado de carga útil.
• Trabajador de Correo Electrónico: renderiza plantillas, admite resúmenes instantáneos, horarios y diarios; maneja rebotes/quejas a través de webhooks del proveedor y mantiene una lista de supresión.
• Todos los trabajadores son consumidores idempotentes con clave notification_id y escriben el estado terminal de vuelta a un tópico delivery.status.

Escritor de Historial y Ruta de Lectura

• Consumidor que persiste notificaciones y mantiene contadores de no leídos en Redis (contador autoritativo reconciliado periódicamente desde la tienda).
• La API de lectura sirve las últimas 100 notificaciones de la tienda de historial, con una caché de Redis de la primera página por usuario para lecturas típicas de menos de 10 ms.

Servicios de Soporte

• Servicio de Plantillas: plantillas localizadas y versionadas con interpolación de variables; desacopla los cambios de copia de los despliegues de código.
• Registro de Dispositivos: token_dispositivo, plataforma, version_app, locale, timezone, last_seen.
• Tienda de Deduplicación: Redis con un TTL de 24 h en (producer_id, idempotency_key) para que al menos una vez se comporte como efectivamente una vez.
• Programador: para notificaciones retrasadas/programadas y ventanas de resumen (colas agrupadas por tiempo en conjuntos ordenados de Redis o un programador dedicado como una escalera de tópicos de retraso de Kafka).
• DLQ + Replayer: mensajes venenosos estacionados y reproducibles después de las correcciones.

4. MODELO DE DATOS Y ELECCIONES DE BASE DE DATOS

a) Historial de Notificaciones — Cassandra (o ScyllaDB / DynamoDB)
Tabla: notifications_by_user

• Clave de partición: user_id
• Clave de agrupación: created_at DESC, notification_id
• Columnas: type, actor_id(s), target_type, target_id, aggregated_count, preview_text, image_url, deep_link, read_at, channels_sent, created_at
• TTL: 90 días; la aplicación limita las lecturas a 100 filas.
  Justificación: el patrón de acceso es una clave de partición única y bien conocida con una rebanada ordenada por tiempo — exactamente el punto fuerte de Cassandra. Ofrece escalabilidad lineal de escritura (necesitamos 60–100K escrituras/segundo sostenidas), replicación maestra sin maestro multiregión para disponibilidad, consistencia ajustable (escribir QUORUM/LOCAL_QUORUM, leer LOCAL_ONE para el feed), y TTL nativo para la retención. No necesitamos uniones ni transacciones de varias filas aquí, por lo que una tienda relacional solo agregaría dolor de fragmentación y riesgo de amplificación de escritura.

b) Contadores de no leídos y primera página activa — Redis Cluster

• Contador entero unread:{user_id}; lista JSON en caché notif:page0:{user_id}.
  Justificación: los contadores se leen en cada apertura de aplicación (QPS extremadamente alto, bajo valor por lectura) y deben ser de milisegundos de un solo dígito. Redis absorbe esto de manera económica; los contadores de Cassandra son comparativamente costosos y propensos a errores. Los contadores se reconcilian asincrónicamente para que la deriva se autocorrija.

c) Preferencias de usuario y tokens de dispositivo — PostgreSQL (fragmentado por user_id) con caché de lectura anticipada de Redis
Tablas: user_preferences(user_id, category, channel, enabled, quiet_hours_start, quiet_hours_end, timezone, updated_at), devices(device_id, user_id, platform, push_token, locale, last_seen, active), suppression_list(email, reason, created_at).
Justificación: estos datos son de bajo volumen, con muchas lecturas, relacionales (usuarios -> dispositivos -> configuraciones por categoría), y se benefician de transacciones y restricciones para la corrección y la auditoría (los registros de consentimiento tienen peso de cumplimiento). El volumen es lo suficientemente pequeño (~100M de filas) como para fragmentarlo trivialmente y almacenarlo en caché casi por completo.

d) Registro de Conexiones — Redis Cluster

• conn:{user_id} -> conjunto de {device_id, gateway_node_id, connected_at}, TTL 90s refrescado por heartbeat.
  Justificación: efímero, rotación extremadamente alta, debe ser rápido; la durabilidad no es necesaria porque una entrada perdida se degrada con gracia a fallback de push.

e) Deduplicación / idempotencia — Redis con TTL, respaldado por nada (la pérdida solo arriesga un duplicado raro).

f) Plantillas y configuración — PostgreSQL + almacenamiento de objetos para activos, almacenado en caché en el borde.

g) Analítica — eventos transmitidos desde Kafka a un data lake (S3/Parquet) y data warehouse (Snowflake/BigQuery) para informes de tasas de entrega, tasas de apertura y latencia; ClickHouse para dashboards operativos casi en tiempo real.

5. RECOMENDACIONES DE STACK TECNOLÓGICO

• Lenguaje/runtime: Go para la puerta de enlace, la puerta de enlace en tiempo real y los trabajadores (goroutines y baja memoria por conexión se adaptan a millones de sockets); Java/Kotlin aceptable para agregación intensiva de Kafka Streams.
• Mensajería: Apache Kafka (gestionado: MSK/Confluent) como la columna vertebral; tópicos separados por canal y por clase de prioridad. Kafka Streams o Flink para agregación/coalescencia con ventanas.
• Transporte en tiempo real: WebSocket sobre TLS con SSE y fallbacks de long-poll; balanceo de carga NLB/L4 con vaciado de conexión; el enrutamiento pegajoso no es necesario ya que el registro almacena la identidad del nodo.
• Almacenamiento en caché: Redis Cluster (o Elasticache/MemoryDB) para contadores, preferencias, registro, deduplicación, límites de velocidad.
• Almacenes de datos: Cassandra/ScyllaDB para historial; PostgreSQL (Aurora) para preferencias/dispositivos; S3 + data warehouse para analítica.
• Proveedores de push: APNs, FCM, Web Push (VAPID); correo electrónico a través de SES con SendGrid como proveedor secundario detrás de una capa de abstracción de proveedor para failover.
• Infraestructura: Kubernetes con HPA/KEDA escalando en el lag del consumidor de Kafka (no solo CPU), mesh de servicios Envoy/Istio para mTLS y reintentos, Terraform para IaC.
• Observabilidad: rastreo OpenTelemetry (id de rastreo propagado desde el evento productor hasta la confirmación del cliente), métricas Prometheus + Grafana, logs estructurados en Loki/ELK, alertas PagerDuty sobre SLOs.
• Bibliotecas de resiliencia: disyuntores y bulkheads por proveedor externo, limitadores de velocidad de cubo de tokens, retroceso exponencial con jitter.

6. ESTRATEGIAS DE ESCALABILIDAD, LATENCIA Y DISPONIBILIDAD

Escalabilidad

• Todos los componentes sin estado (API, fan-out, enrutador, trabajadores) escalan horizontalmente; el número de particiones de Kafka es el límite de paralelismo, por lo que se deben aprovisionar particiones para 5–10 veces el pico actual desde el primer día (reparticionar es operacionalmente doloroso).
• Autoscale en lag del consumidor con KEDA para que un pico de 5x active el escalado en segundos; mantenga un búfer cálido de 30–40% de margen porque el escalado no es instantáneo.
• Fragmentar por user_id consistentemente en Cassandra, Postgres y Redis para que los datos de un solo usuario estén co-ubicados y la mitigación de particiones calientes sea uniforme.
• Carriles de prioridad: las notificaciones interactivas (DM, comentario en tu publicación) usan un tópico de alta prioridad con grupos de consumidores dedicados; el fan-out masivo/marketing/celebridad usa un carril de baja prioridad limitado. Esto garantiza el SLO de 2 segundos para las notificaciones que los usuarios realmente notan.
• Manejo de celebridades/claves calientes a través del fan-out híbrido push/pull descrito anteriormente, más claves de partición con sal para objetivos extremadamente calientes.

Baja latencia (p99 inferior a 2 s)

• La ruta crítica es intencionalmente corta: adición de API -> Kafka -> fan-out -> acierto de caché de preferencias -> búsqueda de registro -> escritura WebSocket. Todas las búsquedas son en Redis (menos de 5 ms); ninguna escritura de base de datos síncrona bloquea la entrega.
• La persistencia del historial y la analítica son asíncronas, fuera de la ruta de entrega.
• Productores de Kafka ajustados con linger.ms=5 y compresión (lz4) para equilibrar la lotificación con la latencia; los consumidores usan confirmación manual después del procesamiento.
• Despliegue multiregión con usuarios anclados a la región más cercana para reducir el RTT; las conexiones WebSocket terminan en los bordes regionales.
• Las ventanas de agregación son configurables por tipo y se deshabilitan para tipos críticos de latencia como los DM.
• Sondas sintéticas continuas miden la latencia real de extremo a extremo por región y por canal.

Alta disponibilidad (99,9 % +)

• Sin puntos únicos de fallo: multi-AZ para cada nivel, Kafka RF=3 con min.insync.replicas=2, Cassandra RF=3 con escrituras LOCAL_QUORUM, Postgres con standby síncrono y failover automatizado.
• Multiregión activa-activa para los niveles en tiempo real y de entrega; Cassandra replica entre regiones de forma asíncrona, Postgres usa réplicas de lectura regionales con una región de escritura designada.
• Degradación elegante: si la ruta WebSocket no está saludable, recurre al push móvil; si la caché de preferencias está caída, recurre a Postgres y luego a valores predeterminados conservadores; si las escrituras de Cassandra fallan, continúa entregando en tiempo real y reproduce las escrituras de historial desde Kafka después.
• Reintentos con retroceso exponencial más jitter, intentos limitados, luego DLQ con alertas y una herramienta de reproducción.
• Disyuntores por proveedor externo para que una interrupción de APNs no agote los hilos de trabajo y detenga el correo electrónico.
• Entrega al menos una vez más deduplicación de notification_id en el servidor y el cliente; los clientes también se deduplican al reconectarse al reproducir el historial pendiente.
• Prácticas de confiabilidad: ejercicios de caos/juegos (matar un nodo de puerta de enlace y verificar el fallback de push), pruebas de carga al 5x del pico, despliegues blue-green y canary, flags de funciones para interruptores por canal, descarte de contrapresión de tráfico de baja prioridad antes que de alta prioridad.

7. CUELLOS DE BOTELLA Y COMPENSACIONES

Posibles cuellos de botella

• Proveedores de terceros (APNs/FCM/correo electrónico): el techo más difícil, ya que el rendimiento no depende de nosotros. Mitigar con agrupación de conexiones sobre HTTP/2, lotificación, limitadores de velocidad por proveedor, failover multi-proveedor para correo electrónico y suavizado basado en colas de picos.
• Fan-out de celebridades: una sola publicación puede generar decenas de millones de entregas. Mitigado por push/pull híbrido, carriles masivos limitados y agregación.
• Nivel de conexión WebSocket: memoria y descriptores de archivo por nodo, más reconexiones de "rebaño thundering" después de un despliegue o un problema de red. Mitigar con límites de kernel ajustados, reconexión escalonada con jitter y retroceso exponencial forzado en el lado del cliente, y vaciado lento de conexiones durante los despliegues.
• Claves calientes de Redis: la clave de agregación de una publicación viral o un contador compartido. Mitigar con salting de claves, cachés locales en memoria con TTL cortos y fragmentación en el lado del cliente.
• Amplificación de escritura de Cassandra y presión de compactación a 100K escrituras/segundo. Mitigar con compactación de ventana de tiempo (TWCS) adecuada para datos TTL de series temporales, y al no almacenar tipos de notificación de bajo valor en el historial en absoluto.
• Desviación de particiones de Kafka si se particiona por una clave de baja cardinalidad; siempre particionar por recipient_user_id en el tópico de entrega.

Compensaciones explícitas

• Al menos una vez sobre exactamente una vez: exactamente una vez a través de proveedores externos heterogéneos es impráctico y costoso. Aceptamos duplicados raros y los resolvemos con claves de idempotencia y deduplicación en el lado del cliente — más barato y mucho más disponible.
• Consistencia eventual para contadores e historial sobre consistencia fuerte: una insignia de no leído que está momentáneamente desfasada es aceptable; la latencia de varios segundos para garantizarla no lo es. Los trabajos de reconciliación limitan la deriva.
• Persistencia políglota sobre una sola base de datos: esto aumenta la superficie operativa (tres almacenes de datos más Redis) pero cada carga de trabajo obtiene el motor correcto. Un solo clúster de Postgres se convertiría en el cuello de botella con 1000 millones de escrituras/día; un solo clúster de Cassandra haría que las auditorías de preferencias y consentimiento fueran incómodas.
• Fan-out basado en push para la mayoría de los usuarios, basado en pull para celebridades: complejidad de código añadida, pero es la única forma de evitar tormentas de escritura ilimitadas.
• La agregación mejora la experiencia del usuario y reduce drásticamente el volumen de entrega, pero agrega hasta una ventana de latencia para los tipos agregables. Mantenemos las ventanas cortas y eximimos los DM.
• Multiregión activa-activa aumenta el costo e introduce sutilezas de consistencia entre regiones, justificado por los objetivos de disponibilidad y latencia. Si el presupuesto fuera limitado, una postura de región única con standby cálido aún cumpliría el 99,9% pero con un RTO más largo.
• Kafka sobre una cola gestionada más simple (SQS): más carga operativa, pero necesitamos reproducción, particiones ordenadas por clave, grupos de consumidores independientes múltiples y retención de 7 días para recuperación de incidentes.
• Almacenar solo las últimas ~100 notificaciones con un TTL de 90 días intercambia la completitud del archivo por costo y rendimiento de lectura; los datos a largo plazo viven en el data lake de analítica si alguna vez se necesitan.

8. PLAN DE DESPLIEGUE (POR FASES)

Fase 1: API de Ingesta + Kafka + escritor de historial + API de lectura (solo notificaciones en la aplicación). Establece la columna vertebral duradera.
Fase 2: Puerta de enlace en tiempo real, registro de conexiones, contadores de no leídos, entrega WebSocket con fallback de push.
Fase 3: Trabajadores de push móvil y push web, registro de dispositivos, servicio de preferencias y horas de silencio.
Fase 4: Instantáneo de correo electrónico + resúmenes, servicio de plantillas, manejo de supresión.
Fase 5: Agregación/coalescencia, fan-out híbrido de celebridades, limitación de frecuencia.
Fase 6: Multiregión activa-activa, pruebas de caos, validación de carga 5x, dashboards de SLO y presupuestos de error.

9. MÉTRICAS CLAVE Y SLOs

• Latencia p50/p95/p99 de extremo a extremo por canal (SLO: p99 inferior a 2 s para WebSocket).
• Tasa de éxito de entrega por canal; tasas de error del proveedor y tasa de invalidación de tokens.
• Lag del consumidor de Kafka por tópico (señal principal de escalado automático y paginación).
• Conteo de conexiones WebSocket, tasa de rotación y tasa de confirmación.
• Deriva del contador de no leídos detectada por reconciliación.
• Profundidad y antigüedad de la DLQ.
• Disponibilidad por API medida desde la perspectiva del cliente, rastreada contra un presupuesto de error mensual.

Arquitectura de alto nivel:

El sistema está impulsado por eventos. Servicios de productos como Servicio de Seguimiento, Servicio de Publicaciones, Servicio de Comentarios, Servicio de Reacciones y Servicio de Mensajería Directa publican eventos que activan notificaciones en un bus de mensajes duradero. Un Pipeline de Notificaciones consume estos eventos, los enriquece, aplica preferencias de usuario y reglas de deduplicación, persiste los registros de notificaciones y dirige los trabajos de entrega a trabajadores de entrega específicos del canal para notificaciones en tiempo real por websocket/web push, notificaciones móviles y correo electrónico.

Flujo principal:

1. Ocurre una acción del usuario, por ejemplo, el usuario A da "me gusta" a la publicación del usuario B.
2. El servicio de origen escribe su propia transacción comercial y luego publica un evento de notificación en un bróker de mensajes utilizando un patrón outbox o un registro de eventos transaccional.
3. La Ingesta de Notificaciones valida el evento, lo normaliza a un esquema común y le asigna una clave de idempotencia.
4. La distribución y el enrutamiento determinan los destinatarios, el tipo de notificación, la prioridad, la elegibilidad del canal y si el destinatario está en línea.
5. El Almacenamiento de Notificaciones escribe la notificación en el historial de notificaciones del destinatario.
6. Se intenta la entrega en tiempo real a través de conexiones websocket para usuarios web/app en línea y notificaciones push móviles para dispositivos móviles, cuando corresponda.
7. La entrega de correo electrónico se pone en cola por separado, generalmente con procesamiento por lotes y menor prioridad para evitar el envío de spam a los usuarios.
8. El estado de entrega, los reintentos, los fallos y las métricas se rastrean de forma asíncrona.

Estimación de escala:

100 millones de DAU por 10 eventos por día equivalen a 1000 millones de eventos que activan notificaciones por día. La tasa promedio de eventos es de aproximadamente 11.600 eventos por segundo. La carga máxima a 5x es de aproximadamente 58.000 eventos por segundo. El diseño debe prever una distribución interna mayor porque un evento puede notificar a varios destinatarios, especialmente en comentarios, menciones, conversaciones grupales o interacciones en vivo. Un objetivo inicial seguro podría ser de 100.000 a 300.000 entregas de notificaciones por segundo en el pico, dependiendo del comportamiento del producto.

Componentes clave y responsabilidades:

1. Pasarela de API (API Gateway)
   Acepta solicitudes de API externas para leer el historial de notificaciones, marcar notificaciones como leídas, actualizar preferencias de notificación, registrar dispositivos y abrir conexiones websocket. Maneja la autenticación, la limitación de velocidad, el enrutamiento de solicitudes y la protección básica contra abusos.

2. Productores de eventos
   Los servicios de productos existentes generan eventos de dominio como UserFollowed, PostLiked, CommentCreated, UserMentioned, DirectMessageCreated y MessageReactionAdded. Los productores no deben llamar de forma síncrona a los servicios de entrega de notificaciones porque eso acoplaría la latencia del producto a la infraestructura de notificaciones. Publican en un bus de eventos duradero.

3. Bus de eventos o cola de mensajes
   Se recomienda un registro distribuido como Apache Kafka o Apache Pulsar. Proporciona alto rendimiento, almacenamiento duradero, capacidad de reproducción, partición, grupos de consumidores y manejo de contrapresión. Los temas pueden separarse por familia de eventos o prioridad, por ejemplo, interacciones sociales, mensajes directos, entrega de notificaciones-alta, entrega de notificaciones-normal, entrega de notificaciones-correo electrónico.

4. Servicio de Ingesta de Notificaciones
   Consume eventos de producto sin procesar, valida esquemas, filtra notificaciones inválidas/propias cuando corresponda, normaliza las cargas útiles de eventos, genera IDs de notificación y realiza comprobaciones de idempotencia. También enriquece los eventos con metadatos ligeros como el nombre del actor, la referencia del avatar del actor, el ID de la publicación y el tipo de objeto de destino. El enriquecimiento pesado debe minimizarse o realizarse de forma asíncrona para proteger la latencia.

5. Servicio de Distribución (Fan-out Service)
   Determina los destinatarios y crea tareas de notificación por destinatario. Para eventos uno a uno como un "me gusta", un seguimiento o un mensaje directo, la distribución es simple. Para eventos que involucran a varios destinatarios, como menciones, mensajes grupales o hilos de comentarios, la distribución puede generar muchos registros de entrega. Debe admitir tanto la distribución en escritura (fan-out-on-write) como la distribución en lectura (fan-out-on-read) según la escala.

Enfoque recomendado:
Para notificaciones normales, utilice la distribución en escritura y almacene registros de notificación por destinatario. Esto hace que la recuperación del historial sea rápida y habilita los recuentos de no leídos.
Para entidades de distribución muy alta, como transmisiones de celebridades o grupos masivos, utilice la distribución híbrida: almacene un objeto de notificación compartido y materialícelo solo para usuarios activos o bajo demanda.

6. Servicio de Preferencias y Políticas
   Almacena y evalúa las preferencias de notificación del usuario, la configuración de privacidad, las relaciones de silencio/bloqueo, las horas de tranquilidad, los permisos del canal, la configuración regional, el estado de opt-in por correo electrónico y la configuración específica de la plataforma. Devuelve la elegibilidad y la prioridad del canal. Las preferencias deben almacenarse en caché de forma agresiva.

7. Servicio de Almacenamiento de Notificaciones
   Persiste el historial y el estado de las notificaciones. Almacena las últimas N notificaciones, el estado no leído/leído, las marcas de tiempo, el tipo, el actor, las referencias de la entidad y los metadatos de renderizado. Admite consultas como las últimas 100 notificaciones para un usuario, el recuento de no leídos, marcar una como leída, marcar todas como leídas y eliminar/ocultar.

8. Pasarela de Conexión en Tiempo Real (Realtime Connection Gateway)
   Mantiene conexiones websocket o server-sent event para usuarios web y de aplicaciones móviles en línea. Almacena la presencia de la conexión en un almacén de presencia distribuido. Los trabajadores de entrega dirigen las notificaciones en tiempo real al nodo de la pasarela que tiene la conexión activa del destinatario. Para aplicaciones móviles en segundo plano, la entrega recurre a APNs/FCM.

9. Servicio de Presencia
   Rastrea si un usuario está en línea, qué dispositivos están conectados y qué nodo de pasarela posee cada conexión. Los datos de presencia son efímeros y deben almacenarse en Redis Cluster u otra caché distribuida de baja latencia con latidos de TTL cortos.

10. Servicios de Entrega por Canal
    Trabajadores separados entregan notificaciones por canal:
    Trabajador de Notificaciones Push Móviles: Envía a APNs para iOS y FCM para Android. Maneja la invalidación de tokens, los errores del proveedor, los fallos reintentables y las claves de colapso.
    Trabajador de Notificaciones Push Web: Envía notificaciones push web a través del protocolo Web Push para usuarios con suscripciones de navegador registradas.
    Trabajador de Websocket: Envía notificaciones dentro de la aplicación de baja latencia a usuarios en línea a través de la Pasarela en Tiempo Real.
    Trabajador de Correo Electrónico: Envía correos electrónicos a través de un proveedor como SES, SendGrid o un MTA interno. Debe admitir procesamiento por lotes, plantillas, reglas de cancelación de suscripción y colas de menor prioridad.

11. Servicio de Tokens de Dispositivo
    Almacena tokens de dispositivos móviles, suscripciones de notificaciones push web, metadatos del dispositivo, versión de la aplicación, plataforma, idioma y marca de tiempo de la última vez visto. Maneja la rotación de tokens y la limpieza de tokens inválidos.

12. Servicio de Plantillas y Localización
    Renderiza el texto de la notificación y las plantillas de correo electrónico según el tipo de notificación, el idioma, el actor, los metadatos del objeto y las capacidades del cliente. Prefiere almacenar datos de notificación estructurados y renderizar en el momento de la lectura para el historial dentro de la aplicación, mientras que renderiza las cargas útiles finales en el momento de la entrega para notificaciones push/correo electrónico.

13. Servicio de Deduplicación y Agregación
    Evita el spam y las notificaciones duplicadas. Ejemplos: agregar "Alices y otras 12 personas dieron me gusta a tu publicación" en lugar de enviar 13 notificaciones push independientes. Utilice claves de idempotencia como event_type + actor_id + recipient_id + object_id + event_time_bucket. La agregación se puede realizar con conjuntos/contadores ordenados de Redis y luego persistir.

14. Métricas, Registro y Alertas
    Recopila latencia de extremo a extremo, retraso de la cola, tasa de éxito de entrega, tasa de errores del proveedor, recuento de conexiones websocket, tasa de creación de notificaciones, factor de distribución, latencia de la base de datos, precisión del recuento de no leídos y volumen de la cola de reintentos/mensajes fallidos.

Modelo de datos:

1. Esquema de evento de notificación
   notification_event_id: ID único global
   source_event_id: ID del servicio de origen
   event_type: follow, like, comment, direct_message, mention
   actor_user_id: usuario que causó el evento
   recipient_user_ids o referencia del resolvedor de destinatarios
   target_type: post, comment, user, message, conversation
   target_id: ID del objeto de destino
   created_at: hora del evento
   metadata: JSON compacto para contexto adicional
   idempotency_key: clave estable para prevención de duplicados
   priority: high, normal, low

2. Registro de historial de notificaciones
   user_id: clave de partición del destinatario
   notification_id: ID único ordenable por tiempo, por ejemplo, Snowflake/UUIDv7
   notification_type
   actor_user_id o resumen del actor
   target_type
   target_id
   aggregation_key
   summary_text o parámetros de renderizado
   created_at
   read_at (puede ser nulo)
   seen_at (puede ser nulo)
   status: created, delivered, failed, hidden
   channels_attempted
   metadata

Para el almacenamiento del historial, utilice una base de datos de columnas anchas como Apache Cassandra, ScyllaDB o DynamoDB. Particione por user_id y agrupe por created_at descendente o notification_id descendente. Esto coincide con el patrón de consulta principal: obtener las últimas 100 notificaciones para un usuario. Escala horizontalmente, admite un alto rendimiento de escritura y tiene lecturas predecibles de baja latencia. Utilice TTL o compactación en segundo plano para retener el historial reciente según los requisitos del producto, manteniendo al menos las últimas 100. Si se requiere estrictamente "solo las últimas 100", mantenga un trabajo de recorte por usuario o utilice TTL más compactación periódica.

Tabla lógica de ejemplo:
UserNotifications
clave de partición: user_id
clave de agrupación: created_at descendente, notification_id
columnas: type, actor_user_id, target_type, target_id, metadata, read_at, aggregation_key, status

3. Modelo de recuento de no leídos
   Utilice Redis para lecturas y escrituras rápidas del recuento de no leídos, respaldado por almacenamiento duradero en Cassandra/DynamoDB. Incremente en la creación de notificaciones, decremente o restablezca al leer/marcar todo como leído. Dado que los contadores pueden desviarse, reconcilie periódicamente desde el almacenamiento duradero o utilice un modelo de marcador de lectura.

Enfoque alternativo de marcador de lectura:
Almacene last_read_timestamp por usuario y trate las notificaciones más nuevas que esa marca de tiempo como no leídas. Esto hace que "marcar todo como leído" sea barato. Para el estado de lectura por notificación, almacene read_at en registros individuales. A menudo, un híbrido es lo mejor.

4. Preferencias del usuario
   Utilice una base de datos relacional como PostgreSQL o MySQL para registros de preferencias duraderos, ya que las preferencias requieren consistencia, actualizaciones estructuradas y uniones/operaciones administrativas ocasionales. Almacene en caché las preferencias activas en Redis o Memcached. Para una escala muy grande, particione por user_id o utilice DynamoDB si la organización prefiere la escala de clave-valor administrada.
   Esquema de preferencias:
   user_id
   notification_type
   channel: push, web, email, in_app
   enabled: booleano
   quiet_hours
   frequency: immediate, digest, never
   updated_at

5. Tokens de dispositivo y suscripciones push
   Utilice DynamoDB, Cassandra o un almacén relacional particionado con clave user_id y device_id. Las búsquedas de tokens deben ser rápidas y altamente disponibles. Almacene token_hash/token, plataforma, app_version, idioma, enabled, last_seen_at e invalidated_at.

6. Datos de presencia
   Utilice Redis Cluster con TTL:
   user_id -> IDs de conexión activa, IDs de dispositivo, IDs de nodo de pasarela, último latido
   connection_id -> user_id, nodo de pasarela, caducidad
   La presencia puede ser eventualmente consistente, ya que es solo una optimización para la entrega en tiempo real.

7. Estado de entrega y registros de auditoría
   Utilice temas de Kafka más un almacén analítico de menor costo como S3/almacenamiento de objetos, ClickHouse, BigQuery o Elasticsearch/OpenSearch para depuración operativa, análisis e informes de entrega. No coloque registros de entrega de alto volumen en el almacén transaccional principal a menos que sea necesario.

Recomendaciones de pila tecnológica:

Bróker de mensajes: Kafka o Pulsar para streaming de eventos duradero, particionado por recipient_user_id donde el orden por destinatario sea importante. Utilice temas separados para ingesta, distribución, entrega por canal, reintentos y colas de mensajes fallidos.

Bases de datos:
Cassandra/ScyllaDB/DynamoDB para el historial de notificaciones.
PostgreSQL/MySQL o DynamoDB para las preferencias del usuario.
Redis Cluster para presencia y caché activa, caché a corto plazo de idempotencia, límites de velocidad y ventanas de agregación.
Almacenamiento de objetos más base de datos analítica para registros y análisis históricos.

Transporte en tiempo real:
WebSocket para notificaciones en tiempo real dentro de la aplicación y web. Server-Sent Events se puede usar para entrega unidireccional solo web, pero WebSocket es más flexible para acuses de recibo y latidos.

Proveedores de push:
APNs para iOS, FCM para Android, Web Push para navegadores. Abstraiga los proveedores detrás de un Servicio de Entrega de Push para aislar el comportamiento específico del proveedor.

Correo electrónico:
Amazon SES, SendGrid, Mailgun o infraestructura de correo electrónico interna. Utilice colas dedicadas, plantillas, listas de supresión y digestos.

Computación:
Servicios sin estado en Kubernetes o un orquestador similar. Escala automática horizontal de consumidores basada en el retraso de la cola, la CPU y la latencia de entrega. Utilice despliegue regional con balanceadores de carga y descubrimiento de servicios.

IDs:
Utilice UUIDv7, ULID o IDs de Snowflake para IDs de notificación ordenables. Asegure la idempotencia a través de source_event_id y claves de idempotencia específicas de la notificación.

Estrategia de escalabilidad:

1. Particionamiento
   Particione los temas de Kafka por recipient_user_id para el orden por usuario cuando sea necesario. Para eventos de origen con destinatario desconocido, particione por entidad de origen hasta la distribución, luego re-particione por destinatario. Particione el historial de notificaciones por user_id para optimizar las consultas de notificaciones recientes.

2. Escalado horizontal
   Todos los servicios de pipeline deben ser sin estado, excepto las pasarelas y el almacenamiento. Los consumidores se pueden escalar aumentando las particiones de temas y las réplicas de trabajadores. Las pasarelas en tiempo real escalan por recuento de conexiones y ancho de banda.

3. Contrapresión (Backpressure)
   Si los proveedores descendentes se ralentizan, las colas absorben los picos. Utilice colas separadas por canal y prioridad para que los retrasos del correo electrónico no afecten a los mensajes directos o las notificaciones dentro de la aplicación. Aplique límites de velocidad por usuario, por actor, por tipo de notificación y por proveedor.

4. Almacenamiento en caché (Caching)
   Almacene en caché preferencias, tokens de dispositivo, presencia, plantillas y recuentos de no leídos. Utilice TTL cortos para datos que cambian con frecuencia. Las fallas en la caché no deben bloquear toda la entrega; si las preferencias no están disponibles temporalmente, falle de forma segura según las reglas del producto, a menudo enviando solo los registros obligatorios dentro de la aplicación y posponiendo los canales externos.

5. Agregación
   Reduzca la distribución y el volumen de notificaciones push agregando "me gusta" e interacciones similares. Por ejemplo, almacene cada evento de "me gusta" si es necesario para análisis, pero envíe una notificación por publicación por ventana de tiempo: "Alice, Bob y otras 10 personas dieron me gusta a tu publicación".

6. Distribución híbrida (Hybrid fan-out)
   Para escenarios de alta distribución, evite escribir millones de filas inmediatamente. Almacene un evento compartido y materialice las notificaciones para los usuarios activos primero, y luego perezosamente para los usuarios inactivos cuando abran la aplicación.

7. Despliegue multiregión
   Despliegue activo-activo o activo-pasivo entre regiones. Para un tiempo de actividad del 99,9%, se recomienda activo-activo para las pasarelas en tiempo real y los servicios sin estado, mientras que los almacenes de datos deben usar como mínimo replicación multi-AZ. El enrutamiento global de usuarios puede dirigir a los usuarios a la región saludable más cercana. Utilice clústeres de Kafka regionales con replicación o un sistema de streaming multiregión administrado.

Estrategia de baja latencia:

1. Mantenga los servicios de producto desacoplados de la entrega de notificaciones. La publicación de eventos debe ser rápida y confiable.
2. Utilice Kafka/Pulsar con suficientes particiones y consumidores para mantener bajo el retraso de la cola.
3. Utilice Redis para la búsqueda de presencia y las decisiones de enrutamiento.
4. Utilice la entrega por websocket para usuarios en línea, ya que evita la latencia de los proveedores de push de terceros.
5. Persista los registros de notificaciones antes o en paralelo con la entrega, según las necesidades de confiabilidad. Un enfoque común es escribir primero el historial y luego entregar; para una latencia ultrabaja, la entrega y el almacenamiento pueden ocurrir concurrentemente con reintentos idempotentes.
6. Evite uniones síncronas costosas. Los eventos deben incluir suficientes metadatos para el renderizado, o utilizar resúmenes de usuario/objeto almacenados en caché.
7. Priorice los mensajes directos y las notificaciones sensibles a la seguridad sobre las notificaciones sociales de bajo valor.

Confiabilidad y alta disponibilidad:

1. Mensajería duradera
   Utilice replicación de Kafka/Pulsar entre zonas de disponibilidad. Los productores utilizan acuses de recibo y reintentos. Los consumidores confirman los offsets solo después de un procesamiento duradero o después de escribir una salida idempotente.

2. Patrón Outbox
   Los servicios de origen escriben cambios de dominio y eventos salientes transaccionalmente en una tabla outbox. Un relé publica el outbox en Kafka. Esto evita la pérdida de eventos cuando un servicio tiene éxito en la escritura de su base de datos pero falla antes de publicar.

3. Idempotencia
   Cada etapa debe ser idempotente. Se esperan eventos duplicados debido a reintentos. Utilice source_event_id, notification_id e idempotency_key para evitar filas de historial duplicadas y intentos de push duplicados siempre que sea posible.

4. Política de reintentos
   Los fallos transitorios van a temas de reintento con retroceso exponencial y jitter. Los fallos permanentes, como tokens de push inválidos, se manejan marcando los tokens como inválidos. Los mensajes venenosos van a colas de mensajes fallidos para su inspección.

5. Degradación elegante (Graceful degradation)
   Si el proveedor de correo electrónico está caído, ponga en cola el correo electrónico y continúe con las notificaciones dentro de la aplicación. Si los proveedores de push son lentos, entregue por websocket/dentro de la aplicación y reintente el push más tarde. Si la caché de preferencias no está disponible, recurra a lecturas de preferencias duraderas o valores predeterminados conservadores. Si la presencia no está disponible, omita el websocket y confíe en el push/historial.

6. Replicación y copias de seguridad
   Utilice bases de datos multi-AZ, copias de seguridad regulares, recuperación a un punto en el tiempo para almacenes relacionales y procedimientos de restauración probados. Para Cassandra/ScyllaDB, utilice un factor de replicación de 3 entre AZ y configuraciones de quorum apropiadas para las compensaciones de latencia/confiabilidad.

7. Monitoreo y SLOs
   Rastree la latencia de extremo a extremo p50/p95/p99 desde la creación del evento de origen hasta la recepción del cliente. Alerte sobre el retraso de la cola, los picos de fallos de entrega, la limitación del proveedor, las particiones activas de la base de datos, la tasa de desconexión de websocket, la presión de memoria de Redis y las tormentas de reequilibrio de consumidores.

API de historial de notificaciones:

GET últimas notificaciones:
El cliente solicita las últimas 100 notificaciones. La Pasarela de API autentica al usuario, la API de Notificaciones consulta UserNotifications por user_id ordenado por created_at descendente, enriquece los campos de visualización faltantes desde la caché y devuelve registros estructurados.

Marcar notificación como leída:
La API actualiza read_at para esa notificación y ajusta el recuento de no leídos de forma idempotente.

Marcar todo como leído:
Almacena last_read_timestamp para el usuario y opcionalmente actualiza asíncronamente las filas más antiguas no leídas. Esto evita escrituras síncronas grandes.

Posibles cuellos de botella y compensaciones:

1. Explosión de distribución (Fan-out explosion)
   Problema: Algunos eventos pueden notificar a muchos usuarios, abrumando las colas y el almacenamiento.
   Mitigación: Distribución híbrida, colas de prioridad, agregación, límites de velocidad y materialización perezosa.
   Compensación: La distribución en lectura reduce la carga de escritura pero hace que las lecturas sean más complejas y puede aumentar la latencia de lectura.

2. Usuarios activos y publicaciones virales (Hot users and hot posts)
   Problema: Las celebridades o las publicaciones virales pueden generar un gran volumen de notificaciones para un destinatario o un objeto.
   Mitigación: Agregar notificaciones por objeto y ventana de tiempo, particionar claves de agregación y suprimir notificaciones repetidas de bajo valor.
   Compensación: Los usuarios pueden recibir notificaciones menos granulares.

3. Límites de los proveedores de push
   Problema: APNs/FCM/proveedores de correo electrónico pueden limitar o fallar.
   Mitigación: Trabajadores de proveedor dedicados, limitación de velocidad adaptativa, reintentos, limpieza de tokens y retroceso específico del proveedor.
   Compensación: La entrega de push externa no siempre puede cumplir el objetivo de menos de 2 segundos; la entrega por websocket para usuarios en línea es la ruta confiable de baja latencia.

4. Volumen de escritura de la base de datos
   Problema: Las escrituras de notificaciones por destinatario a gran escala pueden ser costosas.
   Mitigación: Utilizar almacenes de columnas anchas optimizados para escritura, lotes de escritura, TTL, agregación y distribución híbrida.
   Compensación: Los almacenes de columnas anchas tienen una flexibilidad de consulta limitada; el diseño debe coincidir con los patrones de acceso.

5. Corrección del recuento de no leídos
   Problema: Los contadores almacenados en caché pueden desviarse bajo reintentos y actualizaciones de lectura concurrentes.
   Mitigación: Actualizaciones idempotentes, marcadores de lectura, reconciliación periódica.
   Compensación: El recuento exacto de no leídos es más costoso que el recuento de no leídos eventualmente consistente.

6. Ordenación
   Problema: Las notificaciones pueden llegar desordenadas debido al procesamiento distribuido.
   Mitigación: Utilizar IDs ordenables y ordenar por hora del evento/ID de notificación al leer. Particionar por destinatario para un ordenamiento más fuerte por usuario cuando sea necesario.
   Compensación: El ordenamiento global estricto no es práctico ni necesario.

7. Latencia versus durabilidad
   Problema: Escribir el historial antes de la entrega mejora la confiabilidad pero aumenta la latencia.
   Mitigación: Utilizar almacenamiento rápido en la región local y paralelizar el almacenamiento/entrega después de la asignación de idempotencia.
   Compensación: La entrega paralela puede mostrar brevemente una notificación enviada antes de que aparezca en el historial si el almacenamiento se retrasa.

8. Complejidad de la evaluación de preferencias
   Problema: Las comprobaciones de preferencias por evento pueden ser costosas en el pico.
   Mitigación: Almacenar en caché las preferencias, precalcular la configuración efectiva e invalidar la caché en los cambios de preferencias.
   Compensación: Los cambios de preferencias pueden tardar unos segundos en propagarse a menos que se requiera una fuerte consistencia.

Resumen del diseño final recomendado:

Utilice una arquitectura impulsada por eventos con Kafka/Pulsar como columna vertebral, servicios de ingesta/distribución/enrutamiento sin estado, Cassandra/ScyllaDB/DynamoDB para el historial de notificaciones por usuario, Redis para presencia y cachés activas, pasarelas websocket para entrega en línea inferior a 2 segundos, APNs/FCM/Web Push para notificaciones de plataforma y un pipeline de entrega de correo electrónico separado. El sistema debe ser escalable horizontalmente, particionado principalmente por user_id, resiliente a través de colas duraderas y procesamiento idempotente, y optimizado para baja latencia a través de almacenamiento en caché, enrutamiento de presencia en línea, colas de prioridad y agregación. Este diseño cumple con los requisitos funcionales, admite los 1000 millones de eventos diarios esperados con picos de 5x y proporciona un camino práctico hacia una disponibilidad del 99,9% con degradación elegante bajo fallos parciales.