E se pudéssemos reconstruir o Kafka do zero?

• O KIP-1150 (Kafka sem disco) e o projeto de fork do Kafka da AutoMQ estão intensificando a discussão sobre um Kafka otimizado para nuvem
• Se o Kafka fosse recriado, a proposta seria remover a estrutura tradicional de partições e adotar uma abordagem centrada em chaves
• Há necessidade de recursos de controle de concorrência e suporte a schema no lado do broker
• Também se destaca a necessidade de integrar características de sistemas modernos, como escalabilidade, snapshots e multitenancy
• Uma reflexão, a partir do Kafka, sobre um verdadeiro sistema de log de eventos cloud-native que vá além dos limites do Kafka atual

---

Se fôssemos reconstruir o Kafka?

• Recentemente foram anunciados o KIP-1150 (Kafka sem disco) e o fork do Kafka da AutoMQ, com o objetivo de integrar o Kafka a object storage como o S3 para melhorar a elasticidade no ambiente de nuvem e reduzir custos
• O texto imagina um sistema de log de eventos cloud-native que supere as limitações do Kafka atual e propõe várias melhorias

Proposta de uma arquitetura sem partições

• Como o object storage em nuvem pode funcionar como armazenamento praticamente infinito, a necessidade de partições de tópico diminui
• Em muitos casos, o que importa é a ordem global das mensagens ou apenas a ordem entre mensagens com a mesma chave
• Seria possível ocultar do usuário o conceito de partição e oferecer uma experiência de uso mais simples

Abordagem centrada em chaves

• A proposta é projetar o sistema para permitir acesso rápido e replay de todas as mensagens de uma chave específica, em vez de depender de varredura por partição
• Isso permitiria suportar fluxos em nível de entidade na casa dos milhões e ajustar dinamicamente o número de consumidores conforme a demanda
• Como as falhas ficam isoladas no nível da chave, a eficiência geral de processamento do sistema aumenta
• É uma estrutura ideal para event sourcing ou sistemas baseados no modelo de atores

Suporte a hierarquia de tópicos

• Como em sistemas como o Solace, seria necessário promover parte do payload da mensagem a um identificador de tópico em formato de caminho estruturado, permitindo assinaturas baseadas em padrões
• Assim, o broker pode oferecer filtragem eficiente de assinaturas sem precisar fazer parsing da mensagem inteira

Recursos de controle de concorrência

• Hoje, o Kafka não oferece um mecanismo para evitar conflitos de concorrência no momento da gravação
• Se houver suporte a optimistic locking por chave, será possível verificar se a mensagem foi gravada depois de observar o estado mais recente
• Isso ajuda a evitar o problema de atualização perdida

Suporte a schema no lado do broker

• Atualmente, o Kafka trata mensagens apenas como arrays de bytes e depende de um schema registry externo
• O texto propõe suporte nativo, no nível do broker, a informações de schema como metadados AsyncAPI para garantir consistência de schema
• Com isso, também seria mais fácil integrar com formatos abertos de tabela como o Apache Iceberg

Escalabilidade e arquitetura de plugins

• Propõe-se uma arquitetura com extensibilidade e capacidade de plugin, como acontece com Postgres e Kubernetes
• Deve ser possível implementar facilmente filtros ou transformações no nível do broker, sem depender de proxies com conhecimento do protocolo, como o Kroxylicious
• Recursos como limitação de taxa, criptografia de tópicos e suporte a backends baseados em tabelas Iceberg deveriam poder ser implementados como plugins

Callbacks síncronos de commit

• Hoje, o Kafka garante apenas consistência eventual
• O texto propõe uma arquitetura em que, após enviar uma mensagem, o producer possa verificar imediatamente se os dados derivados correspondentes já foram atualizados
• Isso permitiria oferecer a garantia de read-your-own-writes e usar o Kafka como um verdadeiro log de banco de dados

Recurso de snapshot

• A compactação atual do Kafka mantém apenas a última mensagem, o que só é válido quando ela contém o estado completo
• Quando apenas mudanças são registradas, é necessário reproduzir todos os eventos de cada chave, o que aumenta o tempo de processamento
• Por isso, seria necessário um recurso de compactação lógica que resuma eventos em snapshots por chave

Suporte nativo a multitenancy

• Todo sistema de dados moderno deveria considerar multitenancy como um requisito básico
• O ambiente para novos tenants precisa poder ser criado de forma barata e imediata, com separação rigorosa de recursos, segurança e controle de acesso

Outras observações

• Alguns recursos já existem em sistemas como S2 (streams de alta cardinalidade), Waltz (optimistic locking) e Apache Pulsar (multitenancy)
• No entanto, ainda não existe um sistema open source que ofereça simultaneamente todos os recursos propostos
• O texto representa a visão pessoal do autor, que trabalha na Confluent, e não uma posição oficial
• Em termos teóricos, menciona-se que uma arquitetura baseada em LSM tree seria uma escolha promissora

[kaydash]

Já chamamos isso de Redis.

[GN⁺]

Comentários do Hacker News

• Concordo. Para certos casos de uso, vale a pena resolver o problema de head-of-line

  • Porém, hoje todos os sistemas de streaming (ou soluções alternativas) incorrem em custo O(n^2) para ack por chave de mensagem
  • Sistemas como o Pulsar são usados com frequência por causa dessa funcionalidade
  • Essa complexidade pode não aparecer todo dia, mas, quando aparece, é preciso esperar
  • Depois de estudar esse problema por muito tempo com colegas, chegamos à conclusão de que é necessária uma mudança arquitetural fundamental para dar suporte escalável a ack por chave de mensagem
  • A arquitetura precisa de um índice ordenado, o que significa processar n mensagens em O(n log n)
  • Queria escrever um blog sobre esse tema, mas não tive tempo
  • Se você pretende depender de ack por chave de mensagem, deve esperar interrupções ou atrasos intermitentes

• O NATS.io é mais fácil de usar do que o Kafka e já resolve vários pontos, como remoção de partições, suporte a streams baseados em chave e uma hierarquia de tópicos flexível

• Minha jornada com o Kafka foi basicamente parecida

  • No começo, pensei: "ah, um log append-only escalável, ótimo e simples"
  • Mas, quando você usa, percebe que ele é muito complexo

• Em certos casos de uso, seria útil se fosse possível garantir que, quando uma solicitação de criação fosse confirmada, a visão derivada dos dados já tivesse sido atualizada

  • Não use Kafka; grave diretamente no armazenamento de dados subjacente
  • Aí você sabe que os dados foram commitados e terá um banco de dados que pode consultar

• Fiz essa pergunta há 6 anos

  • E se fosse escrito em Rust e aproveitasse WASM?
  • Venho trabalhando nisso nos últimos 6 anos
  • Nos últimos 2 anos, venho construindo o Flink usando Rust e WASM

• Armazenamento de objetos para o Kafka? Isso aumentaria a latência e o custo em 10x

  • O Kafka é vítima do próprio sucesso
  • O design é simples e elegante, então está sendo usado para vários propósitos para os quais não foi originalmente projetado
  • Claro, ele não é perfeito para esses casos de uso

• Sobre "remoção de partições" e "streams em nível de chave"

  • Quando o backend de armazenamento depende de particionamento físico, isso é apenas renomear partição para chave e chave para evento

• Vale a pena ficar de olho no Northguard

  • Esse é o nome da reescrita do Kafka no LinkedIn, apresentada em um meetup de processamento de streams cerca de uma semana atrás

• Tenho curiosidade sobre quantos dos problemas do Apache Kafka são resolvidos ao migrar para o Apache Pulsar

  • Pulei o aprendizado de Kafka e fui direto para o Pulsar
  • Atende bem ao nosso caso de uso
  • Não tenho reclamações
  • Mas fico me perguntando por que tão pouca gente o usa

• É um experimento mental útil

  • As respostas que sugerem a conclusão de que o Kafka deveria ser substituído por algo novo são discretas
  • O maior ponto forte do Kafka é o ecossistema amplo e útil construído em torno dele
  • Isso também é uma fraqueza
  • Ele precisa manter algumas decisões de design que hoje não seriam adotadas se tudo começasse do zero
  • Ou então abandonar a retrocompatibilidade e reconstruir o ecossistema que já existe