Uma correção, tá, Fernando? O Kafka, só para não dizer que eu deixei a informação errada, quando você verifica as partições para verificar se elas estão consistentes, porque eu tenho vários brokers que duplicam os dados, a gente usa isso chamado como in-sync replicas, que o líder verifica se os seus followers estão in-sync. Por outro lado, quem gerencia os clusters do Kafka é o Zookeeper. E o Zookeeper ele usa o algoritmo que ele mesmo criou. Ele não é o Raft, ele é, chama Zab Zookeeper Keeper Atomic Broadcast. Uma observação. Boa. Vai fazer a mesma coisa. No geral, os consensos, o líder sempre vai mandar para as réplicas para perguntar o estado dele. Então, isso sempre vai acontecer. Olha que, para mim, essa é a parte mais bonita da computação. A gente começar a entender isso, incluso para como distribuir a minha solução em workloads que são agressivos. Em workloads que são simples, eu acredito que a solução já está ali. Todo mundo já entende a arquitetura de referência. A grande questão é quando a gente começa a falar de coisas, cara, a pessoa respondeu no mercado livre, está lá vendendo, cara. É um peso de workload absurdo, fora do normal. É disso que a gente está falando. É isso que a gente está buscando. Mas existem problemas aqui, nesse conceito distribuído na arquitetura, de forma geral, que a gente também precisa entender antes de trazer uma solução de réplica para eu poder ter os meus dados atualizados de forma consistente ou não para o meu ambiente. E aí, o que eu mais escuto dos fados, dos clientes que utilizam as soluções, o Kafka, que você acabou de falar, cara, putz, mas deu... que eu venho buscando promover, a quantidade de dados que eu tenho é tão grande, mas tão grande, que o meu workload gera uma quantidade de dados que eu tenho é tão grande, mas tão grande, que o meu workload gera uma quantidade de roundtrip entre o líder e as réplicas absurda. Por quê? Você imagina, eu faço um request, mando para o líder, o líder vai mandar esse cara repassar para as réplicas que ele tem, vai buscar o consenso. Quando eu tenho um grande volume disso, eu tenho muito round trip disso, eu acabo impactando essa comunicação, gera um gargalo ali. Certo? E aí é por isso que possivelmente essa solução que o Wesley falou aí do CAP, que é muito personalizada, busca esse menor tempo de consenso para eu dar uma resposta mais rápida, porque ele sabe que ele tem que responder workloads agressivos. Mas eu já vi gente fazer coisas mais simples. Eu buscar, por exemplo, processamentos em batch, eu fazer requests em batch para evitar os round trips para dentro do Kafka. Cara, sensacional. Ele vai responder, eu acabo diminuindo um problema desse, né? Para eu mitigar o tipo de resposta, né? Outro problema, né? É a gente encontrar a quantidade de nós satisfatórios, né? Dessas réplicas, né? Para eu ter o consenso, né? Então, você imagina que quanto mais nós eu tenho, mais dados eu tenho, vai se tornar um problema. Aí a gente pergunta, cara, que tipo de máquina eu vou pensar num cenário desse? E quando eu escuto isso, as pessoas trazerem para mim, qual que é o hardware mais adequado? Com mais capacidade ou de menor capacidade? Olha que como que isso está super relacionado, né? E aí tem outros temas aqui que eu acho que são interessantes. Eles ainda vão precisar estar dentro de um full domain. Porque, lógico, se um cara cair, eu preciso dar uma resposta ainda concisa. E, lógico, eu ainda preciso... A gente chama aqui dentro, e eu vejo dentro de outras empresas, uma validação preventiva. Isso é muito legal. Por que uma validação preventiva? Porque, apesar de eu ter essas réplicas e o líder buscar esse consenso, um erro de software de dados que está ali, a gente aí na gringa, a gente chama isso de fat finger. Não sei se você já escutou disso, Wesley. Não. Não. O fat finger é o erro humano. O dedo gordo lá que o cara, puta, sem querer ele promoveu uma inconsistência numa validação que vai ser replicada entre nós. Então, a gente precisa entender que o erro humano também vai, num ambiente de consenso distribuído, trazer uma problemática. Então, há uma atividade antes de pré-validação disso. Normalmente, a gente usa aí, fora o que a gente chama do fat finger, e usa uma outra expressão, que é o misconfiguration, mas aí é para quando eu tenho uma configuração falha, que me leva isso de forma propagada para dentro do meu cluster. Então, essa avaliação também tem que estar em mente para que eu possa buscar uma consistência adequada. Faz sentido o que eu estou falando até agora? Perfeito, perfeito. Para mim, tá.feito aí uma pergunta que me fizeram cara, legal tem esses nós aí, o líder as réplicas estão acontecendo no banco de dados eu sei que as réplicas vão estar rodando, o que eu como engenheiro ou arquiteto preciso entender sobre essas réplicas meu Kafka está rodando em réplica o meu MainCache também, o meu RabbitMQ, e o RabbitMQ, eu passei num caso com ele, com o MainCache de uma vez, que ele teve um problema de split-brain. Lembra disso, Wesley? Já passou por isso? Split-brain? Inclusive, tem filas novas agora para tentar evitar isso. O tipo da fila, se não me engano, agora, quando ele roda distribuído, que é a Corum, se não me engano, inclusive. Isso, exato. Mas, cara, como que ele funciona? Tem um nome até muito agressivo para isso, mas eu vou ter que falar que é um nome que é usado. Beleza? Quando eu tenho vários nós de réplicas dentro do CAP, que estão buscando muita consistência, para eu eleger um líder, há um algoritmo que chama dispare sobre a cabeça do outro nó. Dispare dentro do tiro sobre a cabeça do outro nó. Por quê? Porque ele fala que dentro dessa distribuição, se a réplica não conseguir se comunicar com o líder, significa que o líder está como? Está fora. Então, o que ele faz? Ele dá um tiro na cabeça para matar o líder e ele assume o lugar do líder. É tão lindo isso. Poético, né? Tanto que o algoritmo, o processo chama shoot the other node in the head ou seja, cara, dá um disparo na cabeça do outro nó dá um tiro na cabeça do outro nó e aí ele assume a posição de líder tá isso porque, pra evitar justamente esse caso aí do split brain que é um caso documentado, que tá na documentação para execução distribuída. Então, a gente já entende, baseado, acho que eu falei, estou falando bastante coisa, a gente entende das limitações, das dificuldades, do teorema de K, como que eu vou aplicar, porque a réplica é importante para ele, certo?