Topologia Confluent Kafka e Consolidação Multiempresa

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 09/07/2026 (58min, pasta Reuniao-ConfluenceKafka) e Ata 04 já consolidada no Assessment (item 1.5) Status: Rascunho para consolidação — a Ata 04 é tecnicamente sólida na maior parte do conteúdo; este artefato visualiza os três achados centrais dela e registra duas ressalvas de fidelidade encontradas na auditoria Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 09/07 foi a primeira apresentação da arquitetura de integrações ao time de assessment, conduzida por Norberto com apoio de João Luiz de Souza Torres, Fabiano Bispo Canedo e Vinicius Batista Pecanha. Já existe Ata 04 cobrindo essa sessão, com boa cobertura técnica — a matemática do ksqlDB, a topologia de produção e o histórico de CDC (GoldenGate → LogMiner → XStream) todos batem com a transcrição. Este artefato traduz os três achados centrais em diagramas para uso no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos), e documenta duas inconsistências que a auditoria de fidelidade encontrou.

Diagrama 1 — Topologia de produção e divisão de responsabilidades

O ponto mais útil deste diagrama para o assessment é a fronteira de responsabilidade: Infraestrutura cuida de tudo abaixo da aplicação (storage, disco, CPU, licenciamento OpenShift), a equipe de Kafka/Confluent cuida dos componentes do barramento em si, DevOps cuida do pipeline de deploy via Azure DevOps, e F5/API Gateway (Sensedia) é operado por outras pessoas dentro do mesmo segmento organizacional. Essa divisão explica por que o assessment já havia identificado, na sessão de OpenShift (20/07), que a equipe responsável pelo barramento é a mesma do API Gateway — informação que se confirma aqui, na sessão anterior, com mais detalhe.

Diagrama 2 — CDC operacional vs. BI: a dor central da sessão

Esta é, segundo a própria Ata 04, "a dor mais imediata": cargas operacionais e de BI/Data Lake competem hoje pelos mesmos 5 pods de Kafka Connect, mesmo tendo perfis de volumetria completamente diferentes. A separação em 3 pods operacionais + 2 pods de BI já está em teste em desenvolvimento, mas a própria equipe reconheceu, na sessão, que tabelas usadas por ambos os domínios vão continuar exigindo tratamento compartilhado — a separação de cluster resolve o caso comum, não o caso geral.

Diagrama 3 — Consolidação multiempresa via ksqlDB: matemática e risco de schema

Este é o achado mais estrutural da sessão: o modelo de nove bancos (um por empresa do grupo) sendo unificado via ksqlDB para simplificar o consumo tem um custo de capacidade que cresce proporcionalmente ao número de tabelas, não ao número de eventos. A conta feita na própria sessão — ~10 estruturas ksqlDB por tabela, ~100 tabelas hoje, ~1000 estruturas no total, com um teto prático de ~100-100 e poucas estruturas por pod — já sinaliza que qualquer projeto novo com dezenas de tabelas adicionais eleva significativamente custo e risco de gargalo. Isso é agravado pelo fato de as nove bases não terem necessariamente o mesmo schema (legado com até décadas de divergência), o que já quebrou em produção uma vez (schema Avro de uma empresa assumido como padrão para todas).

Atualização com evidência real (05/08/2026): a estimativa de "~1000 estruturas ksqlDB" citada na sessão pode agora ser comparada a números reais de produção — o relatório do Confluent Control Center mostra 322 streams e 263 queries persistentes (585 estruturas no total), não ~1000, e 0 tables materializadas (arquitetura 100% stream). A categoria "Outros" do relatório de tópicos soma 791 dos 930 tópicos totais (85%), quase todos a mesma dúzia de tabelas replicadas por sufixo de empresa — confirmando em escala real o padrão de explosão multiempresa discutido nesta sessão, ainda que com número absoluto menor que a estimativa de memória. Ver 030-artefatos/evidencias-producao-confluent-kafka.md, seções A.2 e A.7.

Achados de fidelidade

Auditando a Ata 04 contra a transcrição integral, encontrei dois pontos que vale registrar — nenhum tão grave quanto os erros de fusão de sistemas encontrados nas Atas 02/03 no início do projeto, mas que quebram o padrão de cuidado que a Ata 10 (sessão de OpenShift, posterior) já demonstrava.

Participantes sem lastro na transcrição. A lista de participantes da Ata 04 (item 1.5.3) cita "Gabriel", "Lucas" e "Fabrício" como pessoas citadas ou reconhecidas nominalmente na sessão. Conferi a transcrição inteira — todos os 6 falantes reais (Vladimir, Castellani, Norberto, João Luiz de Souza Torres, Fabiano Bispo Canedo e Vinicius Batista Pecanha) e todas as menções a terceiros — e nenhum desses três nomes aparece em lugar nenhum, nem como fala nem como referência. Isso é diferente do "Guilherme", que também está nessa lista mas tem lastro real, ainda que fraco (Norberto menciona "gulit" ao fim, ao combinar a próxima reunião com F5/API Gateway). A Ata 04 declara duas fontes — "transcrição integral" e "compilação produzida na análise do encontro" — então os três nomes podem vir do segundo documento, ao qual não tenho acesso. Mas, como no caso do Norberto na Ata 10, isso é apresentado sem nenhum hedge, o que destoa do cuidado que a própria Ata 04 demonstra em outros pontos (ex.: a "Nota de registro" sobre ambiguidade de atribuição de falas).

Duração da sessão não bate com a gravação. A Ata 04 registra "Horário: 10h37 às 12h05" e "Duração aproximada: 1h28min". O cabeçalho da gravação (presente no próprio VTT) diz "58m 46s", e o último timestamp da transcrição é 58:27 — ou seja, a fonte primária documenta uma reunião de aproximadamente 58 minutos, não 88. Há uma diferença de meia hora sem nenhuma nota explicando a origem.

Achado menor, de confiança mais baixa: a Ata 04 descreve (item 1.5.2) "uma frente paralela de trabalho com IBM e Confluent, com reuniões recorrentes". A transcrição sustenta apenas uma menção pontual de Norberto a uma conversa com a IBM sobre limitações do ksqlDB — não há evidência textual de uma frente de trabalho formal com cadência recorrente envolvendo as duas empresas juntas.

Próximo passo

Consolidar os três diagramas na Ata 04 (itens 1.5.4, 1.5.6 e 1.5.10) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID) — a consolidação multiempresa via ksqlDB, em particular, já é candidata a risco formal, dado o crescimento medido em estruturas por tabela (agora com número real disponível: 585 estruturas de produção, não mais apenas a estimativa de ~1000). Antes disso, recomenda-se confirmar com quem produziu a "compilação" de apoio à Ata 04 a origem dos três participantes sem lastro na transcrição (Gabriel, Lucas, Fabrício) e a razão da divergência de 30 minutos na duração registrada da sessão.