Mejoras de arquitectura para una canalización de datos en tiempo real sin lag

<p>Este es un artículo sobre la relación entre los Kafka consumer groups y la cantidad de particiones, las dificultades de auto scaling que esto provoca y la introducción de una nueva arquitectura para resolverlo.<br /> <br /> - Introducción al servicio Airbridge y a la carga de trabajo<br /> - Problemas de la arquitectura existente<br /> - Propuesta de una nueva arquitectura<br /> - Opción 1: modelo de driver y executor como Spark Streaming<br /> - Opción 2: modelo desacoplado entre Kafka consumer y application server<br /> - Razones para elegir la opción 2<br /> - Arquitectura del modelo desacoplado entre Kafka consumer y application server<br /> - Consideraciones en la nueva arquitectura<br /> - Dificultades encontradas<br /> - Resultados después de aplicar la nueva arquitectura<br /> - Lo que aún queda por intentar en el futuro</p>

[lamanus]

<p>Guau... yo también uso ECS, pero no había pensado en esto a este nivel; está muy bueno.</p>

[lamanus]

<p>Parece que, al usar envoy, la solicitud para reducir el tráfico entre zonas de disponibilidad estaba en estado pendiente.<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;