Tem uma conversa que eu já tive dezenas de vezes com times de tecnologia, geralmente puxada por alguém querendo justificar uma reescrita: "Kafka já é tecnologia antiga, surgiram coisas novas". E toda vez eu faço a mesma pergunta de volta: antiga comparada com o quê, e resolvendo qual problema?

Porque essa é a confusão que mais vejo em arquitetura de dados hoje: tratar idade como sinônimo de obsolescência. Não são a mesma coisa. E entender a diferença é, sinceramente, um dos trabalhos mais importantes que um CTO tem.

Idade não é o problema. Rigidez é.

O Kafka nasceu em 2011, no LinkedIn, para resolver um problema muito concreto: mover eventos em alto volume, de forma durável, entre sistemas que não deveriam precisar se conhecer diretamente. Quinze anos depois, esse problema não desapareceu, só ficou maior. Toda empresa que opera em escala hoje lida com mais eventos, mais integrações e mais sistemas conversando entre si do que em 2011, não menos.

Um sistema legado de verdade, aquele COBOL rodando num mainframe há 25 anos, aquele monólito Java sem testes que ninguém no time atual escreveu, não é problema porque é velho. É problema porque parou de evoluir. Ninguém mexe nele com confiança, ninguém entende todo o fluxo, e cada mudança é uma aposta. O Kafka, no mesmo período, passou por KRaft substituindo o Zookeeper, por Tiered Storage, por melhorias seguidas em exactly-once semantics. Ele envelheceu evoluindo. É essa a diferença que separa "maduro" de "obsoleto".

O erro caro: trocar de tecnologia em vez de resolver o problema real

Vejo muito disso na prática de modernização, inclusive nos discoverys que fazemos aqui no INDT, no módulo Z/Challanger, quando entramos numa base de código que ninguém quer mais tocar. O instinto de quem sofre com sistema legado é achar que o problema é a stack. Troca-se de linguagem, de banco, de mensageria, e seis meses depois o time percebe que reescreveu o mesmo problema com sintaxe diferente.

O que realmente resolve legado não é a tecnologia nova em si, é entender por que aquele sistema virou uma armadilha. Quase sempre é falta de observabilidade, acoplamento demais

entre módulos que nunca deveriam se conhecer, ausência de testes que permitam mudar com segurança, e documentação que existe só na cabeça de quem não trabalha mais lá. Trocar Kafka por outra fila não resolve nada disso. Resolver isso, sim, é o que faz a modernização valer a pena, com ou sem Kafka no meio do caminho.

Quando trocar de fato faz sentido

Isso não significa que toda decisão antiga deva ser mantida por nostalgia. Existem sinais reais de que uma peça de arquitetura virou passivo técnico: quando o custo operacional dela cresce mais rápido que o valor que ela entrega; quando não existe mais gente qualificada disponível no mercado para mantê-la; quando ela trava a evolução do produto porque qualquer mudança pequena exige um projeto inteiro; ou quando o próprio ecossistema em volta dela morreu, sem atualização de segurança, sem comunidade, sem suporte.

Kafka, hoje, não bate em nenhum desses critérios. Tem comunidade ativa, evolução contínua, integração nativa com praticamente tudo que existe em streaming e dados, e um mercado de profissionais que sabe operá-lo. Um mainframe rodando lógica de negócio que só três pessoas na empresa entendem, sem teste automatizado, sem CI/CD, bate em quase todos.

O que eu realmente cobro do meu time

Não é "usar a tecnologia mais nova". É usar a tecnologia certa para o problema, e ter maturidade técnica pra saber distinguir as duas coisas. Prefiro, sempre, um time que mantém um Kafka bem operado, monitorado e documentado do que um time perseguindo a ferramenta do mês só porque ela é mais recente no LinkedIn de alguém.

Modernizar tecnologia não é sobre perseguir novidade. É sobre eliminar o que trava o negócio e manter, com confiança, não por preguiça, o que continua entregando valor. Às vezes isso significa aposentar um sistema que carrega quinze anos de dívida técnica não resolvida. Às vezes significa manter uma peça de infraestrutura com a mesma idade, porque ela nunca parou de evoluir.

A pergunta que eu faço antes de qualquer decisão de modernização nunca é: "Quantos anos essa tecnologia tem". E sim: "Ela ainda está evoluindo, ou só está envelhecendo?".