Melhorando a arquitetura para um pipeline de dados em tempo real sem lag

<p>Este é um relato sobre a relação entre Kafka consumer groups e o número de partitions, a dificuldade de auto scaling causada por isso e a adoção de uma nova arquitetura para resolver o problema.<br /> <br /> - Introdução ao serviço Airbridge e à workload<br /> - Problemas da arquitetura existente<br /> - Proposta de nova arquitetura<br /> - Opção 1: modelo de driver e executor, como no Spark Streaming<br /> - Opção 2: modelo desacoplado entre Kafka consumer e application server<br /> - Motivos para escolher a opção 2<br /> - Arquitetura do modelo desacoplado entre Kafka consumer e application server<br /> - Pontos a considerar na nova arquitetura<br /> - Dificuldades encontradas<br /> - Resultados após aplicar a nova arquitetura<br /> - O que ainda vale tentar no futuro</p>

[lamanus]

<p>Uau... eu também uso ECS, mas nunca tinha refletido sobre isso nesse nível. Muito bom.</p>

[lamanus]

<p>Ao usar o envoy, parece que a solicitação para reduzir o tráfego entre AZs estava em estado de espera.<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;