Diseñar un sistema de notificaciones en tiempo real para un servicio de ride-sharing

Arquitectura de alto nivel (componentes e interacciones) 1) Productores de eventos (servicios de origen) - Servicio de Viaje: emite eventos del ciclo de vida del viaje (conductor_asignado, viaje_completado). - Servicio de Despacho/Asignación: emite conductor_asignado y cualquier evento de reasignación. - Servicio de ETA/Ubicación: calcula continuamente la ETA a partir de flujos GPS del conductor; emite conductor_llegando_pronto cuando se cruza el umbral de ETA (por ejemplo, <=2 minutos) con histéresis. - Servicio de Promociones: crea eventos de campaña con reglas de geosegmentación y definiciones de audiencia. 2) Ingesta de Notificaciones + Bus de Eventos - Todos los servicios publican eventos de dominio en un bus de eventos duradero. - Los eventos están estandarizados (user_id, ride_id, event_type, timestamp, payload, idempotency_key, priority, locale). 3) Orquestador de Notificaciones (reglas + enrutamiento) - Consume eventos del bus. - Aplica reglas de negocio (a quién notificar: pasajero, conductor; horas de silencio; exclusiones voluntarias del usuario; límites de tasa; no molestar; canales de respaldo). - Enriquece notificaciones (obtiene nombre/vehículo del conductor, enlace de recibo, texto de ETA) mediante lecturas en caché. - Produce "trabajos de notificación" en colas específicas del canal con prioridad (transaccional > promocional). 4) Servicio de Usuario/Dispositivo y Preferencias - Almacena tokens de dispositivo (APNs/FCM), plataforma, versión de la aplicación, última vez visto, idioma y preferencias de notificación. - Expone búsqueda de baja latencia (primero caché). 5) Trabajadores de Entrega (adaptadores de canal) - Puerta de Enlace Push: envía a Apple APNs y Google FCM. - Puerta de Enlace SMS (respaldo opcional para mensajes críticos): Twilio o agregador directo. - Puerta de Enlace In-app/WebSocket (opcional): para usuarios actualmente activos en la aplicación. 6) Seguimiento de Entrega + Reintentos + DLQ - Se registran los intentos de entrega (enviado, aceptado por el proveedor, fallido con motivo). - Reintentos automáticos con retroceso exponencial para fallos transitorios. - Cola de mensajes fallidos (dead-letter queue) para mensajes venenosos; alertas y herramientas de repetición. 7) Pipeline de Segmentación Promocional - Constructor de audiencia geográfica: convierte áreas geográficas (celdas geohash/H3) + criterios de elegibilidad en conjuntos de usuarios objetivo. - Utiliza señales de ubicación casi en tiempo real (última ubicación conocida) y/o región de hogar/trabajo. - Genera lotes de trabajos de notificación en colas de menor prioridad con limitación. 8) Observabilidad y Operaciones - Métricas: latencia de extremo a extremo p50/p95/p99, retraso de cola, tasas de error del proveedor, tasas de invalidación de tokens. - Trazado: correlaciona event_id → job_id → provider request_id. - Consola de administración: gestión de campañas, repetición, listas de supresión. Opciones tecnológicas clave y justificación 1) Colas de mensajes / streaming de eventos - Apache Kafka (o equivalentes gestionados como AWS MSK / Confluent Cloud) como bus de eventos central. Justificación: alto rendimiento durante las horas pico, partición para escalado horizontal, registro duradero para repetición, grupos de consumidores para escalado independiente, buen ajuste para procesamiento al menos una vez. - Temas separados para: - eventos-de-viaje (transaccionales) - eventos-eta - eventos-promo - trabajos-de-notificacion-alta (prioridad) - trabajos-de-notificacion-baja (promo) - resultados-de-entrega 2) Almacenes de datos - Tokens de dispositivo y preferencias: DynamoDB (o Cassandra) indexado por user_id. Justificación: lecturas predecibles de baja latencia a escala masiva, alta disponibilidad, fácil escalado horizontal. - Seguimiento de entrega / análisis: - Ruta activa: DynamoDB/Cassandra para estado reciente (último estado por notification_id). - Análisis a largo plazo: data lake (S3/GCS) + data warehouse (Snowflake/BigQuery) alimentado por Kafka Connect. - Metadatos de campaña/audiencia: Postgres (o Aurora) para gestión relacional (campañas, horarios, creatividades). - Caché: Redis (clusterizado) para búsquedas de tokens de dispositivo, caché de preferencias de usuario y fragmentos de plantilla. 3) Servicios de notificación push - APNs para iOS y FCM para Android. Justificación: infraestructura de push oficial, confiable y escalable; admite prioridad y claves de colapso. - Proveedor de SMS opcional para respaldo para cumplir con la confiabilidad para notificaciones transaccionales críticas. 4) Segmentación geográfica - Indexación H3 o Geohash para regiones geográficas. Justificación: mapeo eficiente de lat/lon a celdas discretas; admite la consulta de "usuarios en estas celdas". - Procesamiento de flujos: Kafka Streams / Flink para mantener la membresía de "usuarios en celda" basada en actualizaciones de ubicación. Baja latencia (<2s) y alta confiabilidad (al menos una vez) 1) Estrategia de baja latencia - Priorizar notificaciones transaccionales: - Usar temas/colas de alta prioridad dedicados y grupos de trabajadores. - Aplicar SLAs estrictos por mensaje: ventanas de lotes cortas (o ninguna) para eventos urgentes. - Enriquecimiento primero en caché: - El orquestador lee tokens de dispositivo/preferencias de Redis; recurre a DynamoDB en caso de fallo de caché. - Mantener el payload mínimo; incluir enlaces profundos para obtener detalles en la aplicación. - Minimizar dependencias síncronas: - Los productores publican eventos de forma asíncrona. - El orquestador evita llamar a múltiples microservicios en línea; utiliza datos precalculados (por ejemplo, información del conductor ya en el evento u obtenible de la caché). - Reutilización de conexión y mejores prácticas del proveedor: - Mantener conexiones HTTP/2 persistentes a APNs; reutilizar conexiones FCM. - Usar las marcas de prioridad del proveedor apropiadamente. - Controlar el ruido de "llegando pronto": - El servicio ETA emite solo al cruzar el umbral con enfriamiento (por ejemplo, no reenviar dentro de N minutos) para reducir la carga y mantener la latencia para mensajes críticos. 2) Entrega al menos una vez y corrección - Al menos una vez desde Kafka + confirmaciones del consumidor después del procesamiento. - Idempotencia: - Cada trabajo de notificación lleva una clave de idempotencia determinista (por ejemplo, user_id + ride_id + event_type + version). - El orquestador escribe un registro de "trabajo creado" (o clave de deduplicación) con escritura condicional para evitar la creación duplicada de trabajos en repeticiones. - Los trabajadores de entrega registran intentos indexados por notification_id para evitar dobles envíos cuando sea posible. - Deduplicación a nivel de proveedor: - Usar claves de colapso APNs/FCM para ciertos tipos (por ejemplo, conductor llegando pronto) para asegurar que lo último reemplace a lo anterior. - Política de reintentos: - Fallos transitorios: reintentar con retroceso exponencial y jitter. - Fallos permanentes (token inválido): marcar token como inválido, dejar de reintentar. - DLQ para fallos repetidos; flujos de operador para repetición. 3) Confiabilidad y disponibilidad - Despliegue multi-AZ para Kafka, Redis, DynamoDB (gestionado) y servicios sin estado. - Contrapresión: - Si los proveedores de push se degradan, las colas absorben los picos; los trabajadores escalan pero se limitan para evitar los límites de tasa del proveedor. - No se requiere entrega exactamente una vez; al menos una vez más idempotencia es suficiente para notificaciones dirigidas al usuario. Escalado para manejar cargas pico 1) Estimación de rendimiento (orden de magnitud) - 500k viajes/día; cada viaje puede generar 2-4 notificaciones transaccionales (asignado, llegando pronto, completado/recibo) para el pasajero; más notificaciones para el conductor. - Los picos durante la hora pico pueden ser de 10 a 20 veces el promedio. Diseñar para varios miles de notificaciones/segundo en ráfagas sostenidas. 2) Enfoque de escalado horizontal - Partición de Kafka: - Particionar por user_id (o ride_id) para mantener el orden por usuario/viaje para notificaciones relacionadas. - Escalar particiones para igualar el paralelismo esperado del consumidor pico. - Servicios sin estado: - El orquestador y los trabajadores de entrega no tienen estado y se escalan automáticamente (HPA de Kubernetes basado en CPU + retraso de cola). - Grupos y aislamiento separados: - Temas/colas y despliegues de trabajadores separados para transaccionales vs promocionales. - Cuotas estrictas para que las promociones nunca agoten la entrega transaccional. 3) Escalado de mensajes promocionales - Precalcular audiencia: - La campaña se expande a celdas H3; obtener usuarios elegibles a través del almacén "usuarios-en-celda". - Abanico en lotes con limitación; encolar trabajos en la cola de baja prioridad. - Limitación de tasa: - Límites globales y por región; división temporal entre celdas. - Respetar límites de frecuencia por usuario y exclusiones voluntarias. 4) Escalado de datos y caché - Cluster Redis dimensionado para altas lecturas QPS; usar hash consistente y replicación. - DynamoDB/Cassandra con suficiente capacidad de lectura; la caché lo protege durante los picos. - Manejo de invalidación de tokens para reducir envíos fallidos repetidos. Principales compensaciones 1) Al menos una vez vs exactamente una vez - Compensación: al menos una vez puede causar duplicados; exactamente una vez agregaría complejidad y latencia. - Decisión: aceptar al menos una vez con claves de idempotencia y claves de colapso sólidas para minimizar duplicados visibles para el usuario. 2) Consistencia vs disponibilidad - Los tokens/preferencias de dispositivo pueden estar ligeramente desactualizados (consistencia eventual) si un usuario cambia la configuración. - Decisión: favorecer la disponibilidad y la baja latencia; usar cachés con TTL cortas y versionado para converger rápidamente. 3) Costo vs rendimiento - Mantener un índice de audiencia geográfica en tiempo real y un procesador de flujos cuesta más que la segmentación por lotes. - Decisión: usar segmentación geográfica casi en tiempo real solo cuando sea necesario; de lo contrario, permitir campañas con expansión por lotes más lenta. Aislar cargas de trabajo promocionales en capacidad más barata. 4) Enfoque de enriquecimiento de payload - Mensajes completamente enriquecidos requieren más lecturas síncronas y pueden aumentar la latencia. - Decisión: mantener el payload push pequeño y depender de enlaces profundos; enriquecer solo cuando los datos ya estén en el evento o en caché. 5) Dependencias del proveedor y respaldo - Agregar respaldo SMS aumenta el costo y el alcance del cumplimiento. - Decisión: habilitar el respaldo SMS solo para notificaciones transaccionales críticas (por ejemplo, conductor asignado/llegando) y solo cuando el push falla repetidamente o el usuario no tiene un token válido. Resumen Este diseño utiliza una columna vertebral de streaming de eventos duradera (Kafka), un orquestador de notificaciones basado en reglas y trabajadores de entrega de canales escalables para lograr una entrega de notificaciones transaccionales de menos de 2 segundos con confiabilidad de al menos una vez. Escala horizontalmente a través de partición y escalado automático, aísla el tráfico promocional para proteger los mensajes sensibles al tiempo, y gestiona duplicados a través de idempotencia y claves de colapso del proveedor, al tiempo que equilibra el costo y la complejidad operativa.

Sistema de Notificación de Viajes Compartidos en Tiempo Real: Diseño de Arquitectura de Alto Nivel Descripción General El sistema de notificación debe entregar de manera confiable mensajes sensibles al tiempo a 1 millón de usuarios activos diarios en 500,000 viajes diarios, con una latencia inferior a 2 segundos y garantías de entrega al menos una vez. El diseño sigue una arquitectura de microservicios impulsada por eventos con una clara separación entre la producción de eventos, el enrutamiento, la entrega y el seguimiento. --- 1. Componentes Arquitectónicos de Alto Nivel e Interacciones El sistema se compone de cinco capas principales: Productores de Eventos: Los servicios centrales de coincidencia de viajes y gestión de trayectos emiten eventos de dominio (conductor asignado, conductor llegando, viaje completado, promoción activada) a un intermediario de mensajes central. Estos servicios están completamente desacoplados del sistema de notificación. Intermediario de Mensajes (Bus de Eventos): Una plataforma de streaming distribuida ingiere todos los eventos y los distribuye a los consumidores posteriores. Esta es la columna vertebral de la canalización asíncrona. Servicio Orquestador de Notificaciones: Un microservicio sin estado que consume eventos del intermediario, los enriquece con preferencias del usuario y tokens de dispositivo (obtenidos de un Almacén de Perfiles de Usuario), determina el canal de notificación correcto (push, SMS, en la aplicación) y publica trabajos de notificación formateados en colas específicas del canal. Trabajadores de Entrega de Canal: Grupos de trabajadores dedicados para cada canal (APNs para iOS, FCM para Android, Twilio para SMS, servidor WebSocket para en la aplicación). Cada trabajador consume de su cola, llama a la puerta de enlace de terceros apropiada y registra el estado de entrega. Almacén de Seguimiento y Auditoría de Entrega: Un registro persistente de cada intento de notificación, su estado (enviado, entregado, fallido) y marcas de tiempo. Esto alimenta paneles y lógica de reintento. Resumen del flujo: El servicio de viaje emite un evento → Intermediario de mensajes → El orquestador enriquece y enruta → Cola del canal → Trabajador del canal → Puerta de enlace Push/SMS → Dispositivo. El estado de entrega se registra de nuevo en el almacén de auditoría de forma asíncrona. --- 2. Elecciones Tecnológicas Clave y Justificaciones Intermediario de Mensajes: Apache Kafka. Kafka proporciona streaming de eventos duradero, de alto rendimiento y ordenado con retención configurable. Su modelo de grupo de consumidores permite que múltiples instancias de orquestador procesen eventos en paralelo. El factor de replicación de Kafka (establecido en 3) garantiza que no se pierda ningún evento si falla un nodo del intermediario. Para los picos de hora punta, Kafka absorbe las ráfagas sin retroalimentación en los servicios ascendentes. Orquestador y Trabajadores: Microservicios de Go o Java desplegados en Kubernetes. Go ofrece baja sobrecarga de memoria y alta concurrencia a través de goroutines, ideal para notificaciones I/O-bound. Kubernetes permite el escalado automático horizontal de pods basado en métricas de latencia del consumidor de Kafka. Almacén de Perfiles de Usuario y Tokens de Dispositivo: Redis (primario, para datos calientes) respaldado por PostgreSQL (fuente de verdad). Los tokens de dispositivo y las preferencias del usuario se almacenan en caché en Redis con un TTL. El patrón de caché-as-a-service garantiza que el orquestador recupere los tokens en menos de 1 ms en caso de acierto de caché, evitando cuellos de botella en la base de datos a escala. Puertas de Enlace de Notificaciones Push: Firebase Cloud Messaging (FCM) para Android y Apple Push Notification service (APNs) para iOS. Ambos admiten API de envío por lotes. Para la opción de respaldo por SMS, Twilio proporciona entrega global confiable con recibos de entrega. Canal en la Aplicación / Tiempo Real: Una puerta de enlace WebSocket (usando Socket.io o un servidor personalizado respaldado por Redis Pub/Sub) mantiene conexiones persistentes con las sesiones de aplicación activas. Para las notificaciones de conductor llegando y conductor asignado, se intenta primero el canal en la aplicación porque es la ruta de menor latencia. Almacén de Auditoría de Entrega: Apache Cassandra o Amazon DynamoDB. Ambos están optimizados para un alto rendimiento de escritura y patrones de acceso de series temporales. Cada intento de notificación se escribe como un registro inmutable con clave (user_id, notification_id, timestamp). Segmentación Geográfica para Promociones: Un índice geoespacial que utiliza PostGIS o Redis con comandos GEO almacena las últimas ubicaciones conocidas de los usuarios. Un servicio de campaña promocional consulta este índice para crear listas de usuarios objetivo, luego publica eventos de notificación individuales en Kafka, manteniendo uniforme la canalización de entrega. --- 3. Estrategia de Baja Latencia y Alta Fiabilidad Baja Latencia (menos de 2 segundos de extremo a extremo): La ruta crítica para las notificaciones transaccionales (conductor asignado, conductor llegando) es: emisión de evento → ingesta de Kafka (< 10 ms) → procesamiento del orquestador, incluida la búsqueda de tokens en Redis (< 50 ms) → llamada a la API de FCM/APNs (típicamente 100–400 ms) → recepción del dispositivo. La latencia p99 total esperada está muy por debajo de los 2 segundos bajo carga normal. Para minimizar el tiempo de procesamiento del orquestador, la obtención de tokens se realiza a través de una única llamada de canalización de Redis en lugar de búsquedas secuenciales. El orquestador no tiene estado y se escala horizontalmente, por lo que ninguna instancia individual es un cuello de botella. La entrega WebSocket para notificaciones en la aplicación evita las puertas de enlace push por completo, logrando una entrega inferior a 100 ms para los usuarios con sesiones activas. Alta Fiabilidad (entrega al menos una vez): Los desplazamientos del consumidor de Kafka solo se confirman después de que el orquestador haya publicado con éxito el trabajo de notificación en la cola del canal. Si el orquestador falla a mitad del procesamiento, el evento se vuelve a consumir y reprocesar. Los trabajadores de entrega de canal utilizan una clave de idempotencia (derivada de notification_id) al llamar a FCM/APNs, lo que evita notificaciones duplicadas incluso si un trabajador reintenta después de un fallo transitorio. Una cola de mensajes fallidos (DLQ) captura las notificaciones que fallan después de un número configurable de reintentos (por ejemplo, 3 intentos con retroceso exponencial). Un sistema de alerta monitorea la profundidad de la DLQ y activa la escalada de guardia. Para el respaldo por SMS: si la entrega push no se confirma dentro de los 30 segundos (verificado a través de los recibos de entrega de FCM), el sistema recurre automáticamente a SMS para notificaciones críticas (conductor asignado, viaje completado). --- 4. Estrategia de Escalado para Cargas Pico Los picos de hora punta son predecibles (desplazamientos matutinos y vespertinos). El sistema utiliza dos enfoques de escalado complementarios: Escalado Proactivo (Programado): El escalador automático horizontal de pods (HPA) de Kubernetes se precalienta antes de las ventanas pico conocidas utilizando una política de escalado basada en cron. Los recuentos de réplicas del orquestador y de los trabajadores se incrementan 10 minutos antes de la hora punta. Escalado Reactivo: La latencia del consumidor de Kafka se expone como una métrica personalizada al servidor de métricas de Kubernetes. Si la latencia en el tema de notificación excede un umbral (por ejemplo, 10,000 mensajes no procesados), el HPA agrega pods de orquestador automáticamente. Los grupos de trabajadores escalan de manera similar según la profundidad de sus colas. Particionamiento de Kafka: El tema de notificación se particiona por user_id (o ride_id) para garantizar el procesamiento ordenado por usuario mientras se permite un alto paralelismo. Con 100 particiones, hasta 100 instancias de orquestador pueden procesar simultáneamente. Las notificaciones de promoción, que son masivas y no críticas en cuanto al tiempo, se procesan en un tema de Kafka separado de menor prioridad con un grupo de consumidores dedicado. Esto evita que las ráfagas promocionales compitan con las notificaciones transaccionales por los recursos de procesamiento. Escalado de bases de datos: Redis se implementa como un clúster con réplicas de lectura. PostgreSQL utiliza agrupación de conexiones (PgBouncer) y réplicas de lectura para las búsquedas de perfiles. Cassandra escala horizontalmente agregando nodos. Rendimiento estimado: 500,000 viajes/día con un promedio de 3 notificaciones por viaje equivale a 1.5 millones de notificaciones transaccionales por día, o aproximadamente 17 por segundo en promedio. Durante un pico de hora punta de 2 horas que maneja el 30% de los viajes diarios, el rendimiento pico alcanza aproximadamente 70 notificaciones por segundo. Esto está bien dentro de la capacidad de un clúster modesto de Kafka y trabajadores, dejando un amplio margen. --- 5. Principales Compensaciones Entrega al menos una vez vs. Entrega exactamente una vez: La entrega exactamente una vez en sistemas distribuidos y puertas de enlace de terceros (FCM, APNs) es prácticamente imposible de garantizar de extremo a extremo. El diseño acepta semánticas de al menos una vez y mitiga la entrega duplicada utilizando claves de idempotencia. La compensación son notificaciones duplicadas ocasionales (por ejemplo, dos mensajes de "conductor asignado") frente a la complejidad y el costo de latencia de las transacciones distribuidas. Para una aplicación de viajes compartidos, un duplicado raro es mucho menos perjudicial que una notificación perdida. Costo vs. Rendimiento: Mantener una conexión WebSocket persistente para cada usuario activo es costoso en términos de recursos del servidor. El diseño utiliza WebSockets solo para usuarios con sesiones de aplicación activas (típicamente durante un viaje activo), recurriendo a notificaciones push en otros casos. Esto reduce el costo de la infraestructura al tiempo que preserva la baja latencia para los momentos más críticos. Consistencia vs. Disponibilidad: La caché de tokens de Redis puede servir un token de dispositivo obsoleto si un usuario reinstala la aplicación y la caché aún no se ha invalidado. El diseño acepta esta ventana de consistencia eventual (típicamente segundos a minutos) a cambio de los beneficios de disponibilidad y latencia del almacenamiento en caché. Un push fallido debido a un token obsoleto activa una actualización de la caché y un reintento, por lo que el impacto es una notificación ligeramente retrasada en lugar de una perdida. Simplicidad vs. Flexibilidad en el Enrutamiento de Canales: Un motor de enrutamiento más sofisticado podría aplicar modelos de aprendizaje automático para elegir el canal óptimo por usuario. El diseño actual utiliza un enrutador simple basado en reglas (en la aplicación primero, luego push, luego SMS de respaldo) para la previsibilidad, menor complejidad operativa y depuración más fácil. Esto se puede evolucionar incrementalmente. Aislamiento de Promociones: Separar el tráfico promocional en su propio tema de Kafka y grupo de trabajadores agrega complejidad operativa (más temas para monitorear, más grupos de consumidores para administrar) pero es una compensación necesaria para proteger los SLAs de notificación transaccional de ser degradados por envíos promocionales masivos. --- Conclusión Esta arquitectura ofrece un sistema de notificación robusto y escalable al combinar el streaming de eventos duradero de Kafka, el enriquecimiento de baja latencia respaldado por Redis, los trabajadores de entrega multicanal y el escalado automático basado en Kubernetes. El diseño prioriza la entrega inferior a 2 segundos para notificaciones transaccionales y la fiabilidad de al menos una vez a través de reintentos idempotentes y colas de mensajes fallidos, al tiempo que aísla el tráfico promocional para proteger la experiencia central del usuario. Las compensaciones realizadas favorecen la simplicidad operativa y la disponibilidad sobre la perfección teórica, lo cual es apropiado para un producto de consumo de alta rotación.