Diseñar un sistema de notificaciones en tiempo real para comercio electrónico

Resumen Propongo una plataforma de notificaciones escalable horizontalmente y orientada a streaming, construida a partir de microservicios desacoplados y servicios en la nube gestionados. Ideas centrales: usar un registro de eventos duradero para ingesta y repetición (Kafka/Kinesis/Pub/Sub), procesadores de streaming para enriquecer y personalizar eventos, un pipeline de entrega que persiste el estado de entrega y reintenta para garantizar al menos una entrega, y conectores específicos del dispositivo para push (APNs/FCM) y web en tiempo real (WebSocket). El diseño cumple con picos de 100k notificaciones/min (≈1.7k/seg), apunta a una entrega sub-5s para el 99% de los mensajes, y soporta personalización y entrega fiable. Arquitectura de alto nivel (componentes e interacciones) 1) Productores de Eventos - Fuentes: Servicio de pedidos (actualizaciones de pedidos), Servicio de precios (cambios de precios), Marketing/CRM (ventas flash). Cada servicio emite eventos ligeros a la capa de ingesta cada vez que ocurre un cambio relevante. Los eventos incluyen event_id, event_type, payload, timestamp y metadatos (user_ids o product_ids). 2) Ingesta / Registro de Eventos Duradero - Registro particionado gestionado: Apache Kafka (autohospedado o Confluent Cloud) o equivalentes en la nube (AWS Kinesis Data Streams, GCP Pub/Sub). Los productores publican eventos en topic(s) organizados por tipo de evento y clave de partición (user_id o product_id) para preservar el orden cuando sea necesario (p. ej., actualizaciones de pedidos por pedido). - ¿Por qué registro duradero?: proporciona capacidad de repetición, retención para reintentos y suavizado de contrapresión. 3) Procesamiento de Streaming / Capa de Enriquecimiento - Procesadores de streaming sin estado/con estado (Apache Flink, Kafka Streams o Dataflow gestionado) se suscriben a topics de eventos para: validar eventos, enriquecer con perfil de usuario y preferencias, unir con datos de productos/segmentos, y decidir la elegibilidad y prioridad de la notificación (p. ej., actualización crítica de pedido frente a marketing). - Salida: Tareas de Notificación normalizadas (task_id, user_id(s), payload, type, priority, ttl, dedup_key) publicadas en un topic de Tareas de Notificación. 4) Personalización y Segmentación - Las reglas de personalización residen en un servicio que combina: almacén de características / base de datos de perfiles (DynamoDB/Cassandra/Postgres + caché Redis para lecturas frecuentes), y un motor de reglas o modelo de ML. Los procesadores de streaming llaman a este servicio o utilizan búsquedas en caché local para determinar los destinatarios y las variantes de contenido dirigidos. - Para eventos de segmentación amplios (venta flash a un segmento), utilice segmentos precalculados almacenados en un almacén rápido (Redis, Druid o búsqueda en BigQuery/ElastiCache) para expandir a listas de usuarios o para aplicar lógica de filtrado dentro de trabajos de streaming. 5) Orquestación de Entrega / Fan-out - Un servicio de Orquestación de Entrega se suscribe al topic de Tareas de Notificación, evalúa los registros de dispositivos, las reglas de limitación y la estrategia de fan-out. Para notificaciones de un solo usuario (actualización de pedido) crea un trabajo de entrega por dispositivo; para difusión basada en segmentos, se expande a muchos trabajos de entrega a través de una cola particionada. - Los trabajos de entrega se colocan en colas de entrega persistentes por fragmento (topics de Kafka, Redis Streams o SQS con FIFO para el ordenamiento cuando sea necesario). Los trabajos incluyen contadores de reintentos y claves de idempotencia/deduplicación. 6) Trabajadores de Entrega / Conectores - Flota de trabajadores sin estado autoescalada por el rezago de la cola. Cada trabajador extrae trabajos, intenta la entrega a través del conector apropiado para el canal del dispositivo: - Push móvil: FCM (Android) y APNs (iOS) utilizando tokens de dispositivo almacenados en el Registro de Dispositivos. - Web/Navegador: Web Push (VAPID) o conexiones WebSocket persistentes (gestionadas a través de un servicio de conexión como AWS API Gateway WebSocket o clústeres de sockets autohospedados detrás de ELB). - Canales de respaldo: Email (SES/SendGrid) o SMS (Twilio) para notificaciones críticas no entregadas. - Los trabajadores persisten los intentos de entrega (éxito/fallo) en un almacén de Estado de Entrega y emiten eventos de finalización o reintento al registro para monitoreo y reintentos adicionales. 7) Registro de Dispositivos y Preferencias del Usuario - Almacén duradero de user_id -> dispositivos (token, plataforma, último_visto, preferencias, indicadores de opt-in). Utilice DynamoDB/Cassandra para un alto rendimiento de escritura; almacene en caché los dispositivos activos en Redis para búsquedas de baja latencia. 8) Estado de Entrega y Capacidad de Repetición - Todas las tareas de notificación y los intentos de entrega se registran en almacenes duraderos (Kafka + archivo en S3) y una base de datos de Estado de Entrega. Esto permite la entrega al menos una vez, auditoría y reconciliación. Las entregas no confirmadas/fallidas se reintentan por un orquestador de reintentos con retroceso exponencial. 9) Monitoreo, Observabilidad y Cumplimiento de SLA - Métricas: tasa de ingesta, latencia de procesamiento, rezago de cola, tasa de éxito de entrega. Trazas para latencia a nivel de ruta (OpenTelemetry) y alertas para incumplimientos de SLA. Paneles para monitorear la latencia p99 y las tasas de fallo por canal. Elecciones clave de diseño y justificaciones - Registro duradero (Kafka/Kinesis/PubSub): proporciona alto rendimiento y capacidad de repetición, lo cual es esencial para la semántica de al menos una vez y la depuración. La partición por user_id/product_id preserva el orden por entidad (crítico para las actualizaciones de pedidos). El streaming gestionado en la nube reduce la sobrecarga operativa. - Procesamiento de streaming (Flink/Kafka Streams/Dataflow): permite el enriquecimiento y la segmentación en subsegundos cerca de la ingesta. El streaming con estado soporta uniones con ventanas (p. ej., emparejar eventos de caída de precios con listas de deseos) con baja latencia. - Registro de Dispositivos en NoSQL + caché: DynamoDB/Cassandra escala horizontalmente para decenas de millones de usuarios; Redis maneja las búsquedas de ruta activa para decisiones de baja latencia. - Colas de entrega y trabajadores autoescalados: desacoplan el fan-out intensivo del procesamiento upstream, permitiendo una escala elegante durante las ventas flash mientras se controlan los límites de tasa de los proveedores de push downstream. - Conectores de push (APNs/FCM) + WebSockets: los servicios de push minimizan el sondeo del cliente y logran baja latencia. Los WebSockets se utilizan para la entrega en tiempo real dentro de la aplicación/web; si WebSocket no está disponible, se recurre a push o pull. - Al menos una vez, idempotencia y deduplicación: almacenar dedup_key a nivel de tarea y hacer que la entrega sea idempotente en el cliente o usar acuses de recibo del SDK cuando sea posible. En el lado del servidor, dedup por task_id/dedup_key antes de crear notificaciones visibles para el usuario. Cumplimiento de los requisitos - Alto Rendimiento: El registro particionado y los trabajadores autoescalados soportan la escala horizontal; Kafka/Kinesis pueden manejar millones de eventos/segundo con múltiples particiones. 100k/min es modesto para tales sistemas; la arquitectura puede escalar a volúmenes mucho mayores añadiendo particiones y trabajadores. - Baja Latencia: El enriquecimiento en streaming y los conectores directos de push/WebSocket son rutas de baja latencia. Apuntar a <5s p99: mantener el pipeline de procesamiento por debajo de 1-2s (trabajos de streaming), mantener bajo el rezago de la cola de entrega a través de trabajadores autoescalados, y usar cachés de dispositivos para evitar búsquedas en la base de datos en la ruta activa. - Fiabilidad: El registro de eventos duradero + estados de entrega persistidos + orquestador de reintentos garantizan la entrega al menos una vez. Para notificaciones críticas (actualizaciones de pedidos), habilite garantías más sólidas: acuse de recibo síncrono de los servicios downstream y almacenamiento de un recibo de entrega confirmado (p. ej., acuse de recibo del dispositivo o confirmación del canal de respaldo). Utilice retroceso exponencial y escalada a canales alternativos. - Escalabilidad: Todas las piezas con estado utilizan almacenes escalables horizontalmente (Kafka, DynamoDB/Cassandra, clústeres de Redis). Los trabajadores y los procesadores de streaming son contenedores sin estado que se autoescalan. Utilice partición y fragmentación para el crecimiento. - Personalización: Las uniones en tiempo real en los procesadores de streaming más el almacén de perfiles en caché permiten la personalización por usuario. Los segmentos precalculados aceleran los fan-outs grandes (ventas flash) al evitar la evaluación por usuario sobre la marcha. Compromisos (Consistencia, Disponibilidad, Costo) - Consistencia vs Disponibilidad: Favorecemos la disponibilidad y la consistencia eventual para las notificaciones de marketing (aceptable si una promoción llega ligeramente desordenada). Para eventos críticos de pedidos, utilizamos un ordenamiento y persistencia más sólidos (partición y persistencia síncrona) para garantizar el orden correcto y la entrega fiable. Este enfoque híbrido equilibra la experiencia del usuario y la resiliencia del sistema. - Al menos una vez vs Exactamente una vez: Lograr exactamente una vez en todo el pipeline añade complejidad y costo (Kafka transaccional, commit de dos fases, o idempotencia de extremo a extremo). Elegimos al menos una vez con manejadores idempotentes y claves de deduplicación para evitar notificaciones duplicadas visibles, manteniendo el sistema más simple y escalable. - Servicios gestionados vs autohospedados: El streaming gestionado (Kinesis/PubSub) y la infraestructura de push reducen la carga operativa y aumentan la disponibilidad, pero cuestan más. Para la velocidad de comercialización y la fiabilidad a escala, se recomiendan los servicios gestionados. Si el costo se vuelve dominante, considere Kafka autohospedado con automatización sólida. Consideraciones operativas - Limitación de tasa / estrangulamiento: Cuotas por usuario y por proveedor para evitar sobrecargas y rechazos de límites de tasa del proveedor. - Relleno y repetición: Utilice el registro duradero para repetir notificaciones perdidas (p. ej., después de una interrupción) y para reconstruir el estado de entrega. - Pruebas: Pruebas de caos para fallos de particiones y proveedores, pruebas de carga para validar la latencia p99 bajo picos. - Seguridad y privacidad: Cifrar tokens en reposo, rotar credenciales de push, respetar las exclusiones voluntarias y los controles de PII. SLA y KPIs a monitorear - Rendimiento (eventos/min), latencia de procesamiento de streaming (p50/p90/p99), latencia de entrega de extremo a extremo (p50/p90/p99), tasa de éxito de entrega por canal, tasa de reintentos, rezago de cola y rezago del grupo de consumidores. Resumen Este diseño utiliza un registro de eventos duradero y particionado más procesamiento de streaming para enriquecimiento/personalización, un pipeline de entrega persistente con trabajadores autoescalados para fan-out, y conectores específicos del canal (APNs/FCM/WebSocket) para una entrega rápida. Prioriza la disponibilidad y la capacidad de repetición para cumplir con la entrega al menos una vez, utiliza caché y partición para cumplir con baja latencia y alto rendimiento, y se basa en componentes de nube gestionados para reducir la carga operativa al tiempo que permite la escala horizontal para soportar el crecimiento futuro.

Diseño de un Sistema de Notificaciones de Comercio Electrónico en Tiempo Real Descripción general El sistema propuesto es una arquitectura basada en microservicios y orientada a eventos que ingiere eventos de múltiples servicios ascendentes, los procesa y enruta a través de un bróker de mensajes, y entrega notificaciones a 50 millones de usuarios a través de canales móviles y web con garantías de entrega al menos una vez, latencia inferior a 5 segundos en el percentil 99, y la capacidad de sostener 100.000 notificaciones por minuto durante eventos pico. El diseño asume un despliegue nativo en la nube en AWS, aunque los principios se traducen directamente a equivalentes en GCP o Azure. Arquitectura de alto nivel La arquitectura consta de seis capas lógicas: Productores de Eventos, Ingesta de Eventos, Procesamiento y Enrutamiento, Preferencias y Segmentación de Usuarios, Entrega, y Observabilidad. 1. Productores de Eventos Múltiples servicios ascendentes generan eventos que activan notificaciones. Estos incluyen el Servicio de Pedidos (que emite eventos de pedido realizado, enviado, en reparto, entregado), el Servicio de Precios (que emite eventos de caída de precio cuando el precio de un artículo vigilado cae por debajo de un umbral), y el Servicio de Campañas (que emite eventos de inicio de venta flash creados por el equipo de marketing). Cada productor publica un sobre de evento estructurado que contiene un tipo de evento, una marca de tiempo, una carga útil y una clave de idempotencia a una capa de ingesta central. Los productores utilizan una llamada de publicación asíncrona de "disparar y olvidar" para que su propia latencia no se vea afectada. 2. Capa de Ingesta de Eventos — Apache Kafka Todos los eventos fluyen hacia Apache Kafka (Amazon MSK en AWS). Kafka se elige por varias razones. Primero, proporciona registros duraderos y solo de adición con replicación configurable (factor de replicación de 3, min.insync.replicas de 2), lo que significa que una escritura confirmada sobrevive a la pérdida de cualquier bróker individual, apoyando directamente el requisito de fiabilidad. Segundo, el modelo de temas particionados de Kafka permite la escalabilidad horizontal: particionamos el tema de eventos de pedidos por ID de usuario para que todos los eventos de un usuario dado se procesen en orden, mientras que el tema general se puede distribuir en docenas de particiones para absorber el rendimiento pico. Con 100.000 notificaciones por minuto, la tasa promedio es de aproximadamente 1.667 eventos por segundo, muy dentro de la capacidad de un clúster de Kafka modesto, pero el particionamiento nos permite escalar a 10 veces o más sin cambios arquitectónicos. Tercero, Kafka desacopla a los productores de los consumidores, por lo que una desaceleración temporal en la capa de entrega no genera contrapresión en el servicio de pedidos. Diseño de temas: temas separados para eventos de pedidos, eventos de precios y eventos de campañas. Esto permite grupos de consumidores independientes con diferentes políticas de escalado y reintento. Compromiso considerado: Evaluamos Amazon SQS más SNS como una alternativa administrada más simple. SQS satisfaría la entrega al menos una vez y es operativamente más ligero, pero carece de las garantías de ordenación de Kafka por partición y su capacidad de repetición, lo cual es valioso para reprocesar después de un error. El costo operativo adicional de Kafka se justifica por los beneficios de ordenación y repetición a nuestra escala. 3. Capa de Procesamiento y Enrutamiento — Servicio de Notificaciones Un microservicio escalado horizontalmente, el Servicio de Notificaciones, consume de los temas de Kafka. Realiza varias tareas. Primero, resuelve la audiencia objetivo. Para eventos de pedidos, el objetivo es un solo usuario (extraído de la carga útil). Para eventos de caída de precio, consulta el Servicio de Lista de Deseos o una vista materializada precalculada para encontrar a todos los usuarios que vigilan ese artículo. Para eventos de venta flash, consulta el Servicio de Segmentación para resolver un segmento de usuario. Segundo, enriquece la notificación obteniendo el nombre de visualización del usuario, la URL de la imagen del producto y la plantilla de mensaje localizada de un Servicio de Plantillas respaldado por una caché de Redis sobre una tienda PostgreSQL. Tercero, aplica las preferencias del usuario. Cada usuario tiene un documento de preferencias (almacenado en DynamoDB para acceso a clave-valor de baja latencia) que especifica los canales optados (push, correo electrónico, SMS, en la aplicación), horas de silencio e intereses de categoría. El servicio filtra y respeta estas preferencias, lo que apoya directamente el requisito de personalización. Cuarto, distribuye las tareas de entrega. Para cada par usuario-canal resuelto, el servicio produce un mensaje de entrega en un tema de Kafka por canal (entrega push, entrega de correo electrónico, entrega de SMS, entrega en la aplicación). Este paso de distribución es crítico: convierte un evento lógico en potencialmente millones de tareas de entrega individuales (para una venta flash dirigida a todos los usuarios), y Kafka absorbe este estallido. Escalado: El Servicio de Notificaciones se ejecuta como una Implementación de Kubernetes (Amazon EKS) con un Autoscalador Horizontal de Pods basado en el rezago del consumidor de Kafka. Durante una venta flash, el rezago del consumidor se dispara y se inician pods adicionales en segundos. Idempotencia: Cada mensaje de entrega lleva la clave de idempotencia del evento original combinada con el ID de usuario. Los trabajadores de entrega descendentes utilizan esta clave compuesta para la deduplicación, asegurando que, aunque Kafka proporcione semántica de al menos una vez, los usuarios no reciban notificaciones duplicadas. 4. Preferencias y Segmentación de Usuarios Las preferencias del usuario se almacenan en Amazon DynamoDB, particionadas por ID de usuario. DynamoDB se elige por su latencia de lectura de un solo dígito de milisegundos y su escalabilidad horizontal sin problemas, lo cual es importante porque cada notificación individual requiere una búsqueda de preferencias. Una caché DAX (DynamoDB Accelerator) se sitúa delante para las claves calientes. Para la segmentación (dirigida a usuarios interesados en una categoría o usuarios en una región geográfica), mantenemos listas de membresía de segmentos precalculadas. Un trabajo por lotes nocturno (Apache Spark en EMR) y un procesador de flujo en tiempo real (Kafka Streams o Flink) mantienen estas listas actualizadas en una tabla DynamoDB separada con clave por ID de segmento, con el valor siendo una lista de IDs de usuario almacenados en S3 para segmentos muy grandes. Cuando el Servicio de Campañas crea una venta flash dirigida al segmento de electrónica, el Servicio de Notificaciones lee la membresía del segmento y la itera, produciendo tareas de entrega en lotes. Compromiso: Precalcular segmentos intercambia almacenamiento y desactualización (un usuario que cambió sus preferencias hace una hora podría seguir estando en el segmento antiguo) por velocidad de consulta. La evaluación de segmentos en tiempo real en el momento de la entrega sería más precisa, pero requeriría escanear millones de registros de usuarios bajo presión de tiempo, violando el requisito de latencia. El enfoque híbrido (lotes nocturnos más actualizaciones de flujo en tiempo real) mantiene los segmentos actualizados en cuestión de minutos. 5. Capa de Entrega Grupos de consumidores separados manejan cada canal. Notificaciones Push (Móvil): Los trabajadores consumen del tema de entrega push y llaman a Firebase Cloud Messaging (FCM) para Android y Apple Push Notification Service (APNs) para iOS. Utilizamos FCM como puerta de enlace unificada para ambas plataformas siempre que sea posible. Los trabajadores agrupan las solicitudes a la API HTTP v1 de FCM (hasta 500 mensajes por llamada de lote) para maximizar el rendimiento. Las entregas fallidas (tokens inválidos, límites de tasa) se reintentan con retroceso exponencial. Los tokens permanentemente fallidos (dispositivos no registrados) activan un evento asíncrono para purgar el token del Registro de Dispositivos de Usuario. Web Push: Los trabajadores envían mensajes del Protocolo Web Push utilizando el estándar VAPID. La suscripción push del usuario (URL del endpoint y claves) se almacena en el Registro de Dispositivos de Usuario (DynamoDB). Este canal reutiliza el mismo tema de entrega push con un campo de subtipo de canal. Notificaciones en la Aplicación: Para los usuarios que están actualmente en línea, mantenemos conexiones WebSocket persistentes a través de una API WebSocket de API Gateway (AWS API Gateway WebSocket o un servicio autogestionado que usa Socket.IO en EKS). Un Registro de Conexiones (Redis Cluster) mapea los IDs de usuario a los IDs de conexión WebSocket. El trabajador de entrega en la aplicación busca la conexión y, si el usuario está conectado, envía la notificación en tiempo real. Si no está conectado, la notificación se escribe en una Bandeja de Entrada en la Aplicación (tabla DynamoDB particionada por ID de usuario, ordenada por marca de tiempo) y se entrega cuando el usuario abre la aplicación la próxima vez. Esta doble escritura asegura que ninguna notificación se pierda incluso si el usuario está desconectado. Correo Electrónico y SMS: Canales de menor prioridad. Los trabajadores consumen de los temas de entrega de correo electrónico y SMS y llaman a Amazon SES y Amazon SNS (SMS) respectivamente. Estos canales tienen una latencia aceptable más alta (30 segundos a minutos), por lo que pueden escalarse de manera más conservadora. Garantías de Entrega: La entrega al menos una vez se logra de extremo a extremo. Los consumidores de Kafka confirman los offsets solo después de que la API de entrega descendente confirma la recepción (o el mensaje se persiste en la bandeja de entrada en la aplicación). Si un trabajador falla antes de confirmar, el mensaje se vuelve a entregar. La clave de idempotencia en cada etapa evita duplicados visibles para el usuario. 6. Seguimiento del Estado de la Notificación Un Servicio de Estado ligero registra el ciclo de vida de cada notificación: creada, enviada, entregada, leída. Los recibos de entrega de FCM/APNs y los recibos de lectura de la aplicación cliente se ingieren a través de un tema de Kafka y se escriben en una tienda de series temporales (Amazon Timestream o ClickHouse) para análisis, y en DynamoDB para consultas de estado por usuario (para que la aplicación pueda mostrar insignias de leído/no leído). Estos datos también alimentan la lógica de reintento: si una notificación push no se confirma como entregada en 30 segundos, el sistema puede recurrir al correo electrónico. 7. Observabilidad Prometheus y Grafana monitorean el rezago del consumidor de Kafka, los percentiles de latencia de entrega, las tasas de error por canal y el rendimiento. Se activan alertas si la latencia de entrega p99 excede los 4 segundos (dando un búfer de 1 segundo antes del SLA de 5 segundos). El rastreo distribuido (OpenTelemetry con Jaeger) rastrea un evento desde el productor hasta la entrega, lo que permite una depuración rápida. Los registros estructurados se envían a Amazon OpenSearch para búsqueda y auditoría. Abordando los Requisitos Alto Rendimiento: Los temas particionados de Kafka y los grupos de consumidores escalados horizontalmente manejan 100K notificaciones por minuto cómodamente. La distribución para campañas grandes es absorbida por el búfer de Kafka, y los trabajadores de entrega se escalan automáticamente según el rezago. Baja Latencia: La ruta crítica para una notificación de un solo usuario (por ejemplo, pedido enviado) es: el productor publica en Kafka (menos de 50 ms), el Servicio de Notificaciones consume y enriquece (menos de 100 ms incluyendo búsquedas en DynamoDB y Redis), el trabajador de entrega envía a FCM/APNs (menos de 500 ms típicos). Total muy por debajo de 5 segundos. Para campañas de distribución masiva, el sistema se paraleliza en muchos trabajadores de entrega; el particionamiento de Kafka asegura que ningún trabajador individual sea un cuello de botella. Fiabilidad: La replicación de Kafka, la gestión de offsets del consumidor y la entrega idempotente garantizan semántica de al menos una vez. Una cola de mensajes fallidos (DLQ) captura los mensajes que fallan después de un número configurable de reintentos, y un equipo de operaciones es alertado para investigar. Las notificaciones de pedidos críticas se marcan con un campo de prioridad y se enrutan a una partición dedicada de alta prioridad con su propio grupo de consumidores, asegurando que nunca sean desatendidas por una avalancha de notificaciones promocionales. Escalabilidad: Cada componente escala horizontalmente. Las particiones de Kafka se pueden aumentar. Los pods de Kubernetes se escalan automáticamente. DynamoDB escala bajo demanda. No hay puntos únicos de fallo ni cuellos de botella de un solo hilo. Personalización: Las preferencias del usuario en DynamoDB controlan la selección del canal y las horas de silencio. Los segmentos precalculados permiten campañas dirigidas. El Servicio de Plantillas admite plantillas de mensajes por idioma, por categoría, y las variantes de prueba A/B se pueden seleccionar en el momento del enriquecimiento. Compromisos Clave y Justificaciones Consistencia vs. Disponibilidad: El sistema favorece la disponibilidad (AP en términos CAP). Si la tienda de preferencias no es accesible momentáneamente, el Servicio de Notificaciones utiliza una preferencia en caché o predeterminada en lugar de bloquearse. Esto significa que un usuario podría recibir ocasionalmente una notificación en un canal del que acaba de darse de baja, pero ninguna notificación se pierde o retrasa. Para un sistema de notificaciones de comercio electrónico, la disponibilidad y la baja latencia son más valiosas que la estricta consistencia de las preferencias. Al Menos Una Vez vs. Exactamente Una Vez: La entrega verdaderamente exacta una vez a través de sistemas externos (FCM, APNs) no es práctica. En su lugar, garantizamos al menos una vez y utilizamos claves de idempotencia para suprimir duplicados a nivel de aplicación. Esto es más simple, más barato y suficiente. Servicios Administrados vs. Autoalojados: Utilizamos Kafka administrado (MSK), Kubernetes administrado (EKS) y bases de datos administradas (DynamoDB) para reducir la carga operativa. El compromiso es un costo por unidad más alto en comparación con el autoalojado, pero el tiempo de ingeniería ahorrado y la fiabilidad de los servicios administrados lo justifican a nuestra escala. Push vs. Pull para En la Aplicación: WebSockets (push) proporcionan la menor latencia para usuarios en línea, pero requieren mantener conexiones persistentes y un registro de conexiones. El sondeo sería más simple, pero añadiría segundos de latencia y generaría carga innecesaria. El enfoque híbrido (WebSocket cuando está en línea, bandeja de entrada cuando está desconectado) equilibra la latencia y el uso de recursos. Consideraciones de Costo: Los mayores impulsores de costos son el rendimiento de Kafka (precios de MSK), la capacidad de lectura de DynamoDB para búsquedas de preferencias y las llamadas a la API de FCM/APNs (gratuitas para FCM, pero la infraestructura para llamarlas a escala no lo es). Para controlar los costos, agrupamos las llamadas de FCM, utilizamos precios bajo demanda de DynamoDB (que es rentable para cargas de trabajo intermitentes) y utilizamos instancias spot para trabajadores de entrega no críticos (correo electrónico, SMS). Conclusión Esta arquitectura proporciona un sistema de notificaciones robusto, escalable y de baja latencia adecuado para una plataforma de comercio electrónico de 50 millones de usuarios. Al aprovechar Kafka como el sistema nervioso central, DynamoDB para el acceso rápido a datos de usuario y trabajadores de entrega específicos del canal que escalan automáticamente de forma independiente, el sistema cumple todos los requisitos establecidos y al mismo tiempo sigue siendo operativamente manejable y rentable. El diseño es extensible: agregar un nuevo canal de notificación (por ejemplo, WhatsApp) solo requiere un nuevo trabajador de entrega que consuma de un nuevo tema de Kafka, sin cambios en los productores de eventos ascendentes ni en la lógica de procesamiento central.