Entrevistas sobre Kafka testam se você entende como os dados se movem através de um log: como os tópicos são divididos em partições, qual ordenação você pode garantir, como os consumidores compartilham o trabalho e o que acontece quando algo falha. Perguntas de cenário sobre lag, duplicatas e perda de dados são comuns, porque esses são os problemas que as pessoas enfrentam em produção.
Abaixo estão 22 perguntas com respostas. Detalhes como valores padrão variam entre versões do Kafka, então mencione que você verificaria a versão em uso.
Conceitos fundamentais
1. O que é o Kafka e para que ele é usado?
O Kafka é um log de commits distribuído e replicado. Os produtores acrescentam registros aos tópicos, e os consumidores os leem no seu próprio ritmo. Ele é usado para streaming de eventos, pipelines de logs e métricas, desacoplamento de serviços, alimentação de dados em sistemas de analytics e processamento de streams.
2. O que são tópicos, partições e offsets?
Um tópico é um fluxo nomeado de registros. Cada tópico é dividido em partições, e cada partição é um log ordenado e somente de acréscimo. Cada registro em uma partição tem um offset, um número sequencial que identifica sua posição. Os offsets são únicos apenas dentro de uma partição.
3. Como as partições afetam a ordenação?
O Kafka garante ordenação apenas dentro de uma partição. Registros com a mesma chave vão para a mesma partição por padrão, então eles mantêm a ordem entre si. Entre partições não há ordenação. Se você precisa de todos os eventos de um cliente em ordem, use o ID do cliente como chave.
4. O que é um broker e o que o controller faz?
Um broker é um servidor Kafka que armazena partições e atende clientes. Um cluster tem vários brokers. Um deles atua como controller, que gerencia os metadados do cluster e a liderança das partições. Versões mais recentes do Kafka usam o KRaft, um mecanismo de consenso integrado, em vez do ZooKeeper para esses metadados.
5. Como funciona a replicação?
Cada partição tem um fator de replicação. Uma réplica é a líder, que processa leituras e escritas, e as outras são seguidoras que a copiam. As réplicas em sincronia (ISR) são aquelas que estão em dia com a líder. Se a líder falhar, uma nova líder é escolhida entre as ISR.
Produtores
6. O que significam as configurações de acks?
| acks | Significado | Tradeoff |
|---|---|---|
| 0 | O produtor não espera por nenhuma confirmação | Mais rápido, pode perder dados |
| 1 | A líder confirma após escrever | Pode perder dados se a líder falhar antes de replicar |
| all | A líder espera por todas as réplicas em sincronia | Maior durabilidade, maior latência |
Para escritas duráveis, use acks=all com min.insync.replicas definido como pelo menos 2 e um fator de replicação de 3.
7. Como você evita mensagens duplicadas de um produtor?
Habilite o produtor idempotente (enable.idempotence=true), que permite ao broker descartar duplicatas causadas por retentativas dentro de uma partição. Para escritas que precisam abranger várias partições ou tópicos de forma atômica, use transações.
8. Como um produtor escolhe uma partição?
Se você fornecer uma chave, o particionador padrão aplica um hash nela para escolher a partição. Sem chave, o produtor distribui os registros entre as partições (versões recentes usam uma abordagem sticky para preencher lotes de forma eficiente). Você também pode escrever um particionador personalizado.
9. O que afeta a vazão do produtor?
Batching (batch.size, linger.ms), compressão (como lz4 ou zstd), o número de partições e acks. Lotes maiores e compressão geralmente aumentam a vazão ao custo de um pouco de latência.
Consumidores
10. O que é um grupo de consumidores?
Um conjunto de consumidores que dividem o trabalho de ler um tópico. Cada partição é atribuída a um consumidor do grupo por vez. Assim, o número de consumidores úteis em um grupo é limitado pelo número de partições, e os consumidores extras ficam ociosos.
11. O que acontece durante um rebalanceamento?
Quando um consumidor entra ou sai, ou as partições mudam, o grupo reatribui as partições. Durante um rebalanceamento clássico, o consumo é pausado enquanto isso acontece. O rebalanceamento cooperativo e a associação estática reduzem a interrupção. Rebalanceamentos frequentes geralmente vêm de consumidores que demoram demais para processar (max.poll.interval.ms) ou que perdem heartbeats.
12. Como os offsets são confirmados?
Os consumidores confirmam o offset do próximo registro a ser lido, armazenado em um tópico interno. A confirmação automática é simples, mas pode confirmar antes que o processamento termine. As confirmações manuais após o processamento dão a você controle sobre o que significa "concluído".
13. O que significam no máximo uma vez, pelo menos uma vez e exatamente uma vez?
- No máximo uma vez: confirme o offset antes do processamento. Uma falha pode perder registros.
- Pelo menos uma vez: processe, depois confirme. Uma falha pode causar reprocessamento, então duplicatas são possíveis.
- Exatamente uma vez: o efeito acontece uma vez. No Kafka, isso é possível dentro do próprio Kafka usando produtores idempotentes, transações e consumidores read_committed. Ao escrever em um sistema externo, você geralmente precisa de escritas idempotentes ou deduplicação por uma chave.
Uma boa resposta diz que "exatamente uma vez" depende de onde estão os efeitos colaterais.
14. Como você lidaria com uma mensagem envenenada que sempre falha?
Capture o erro, tente novamente um número limitado de vezes, depois envie o registro para um tópico de mensagens mortas com os detalhes, confirme o offset e siga em frente. Configure alertas no tópico de mensagens mortas para que alguém investigue.
Operações e cenários
15. O lag do consumidor está crescendo. Como você diagnostica isso?
- Verifique quais partições têm lag. Uma partição sobrecarregada aponta para uma chave desbalanceada. Lag em todas aponta para processamento lento ou consumidores de menos.
- Verifique o tempo de processamento por registro e as chamadas a sistemas downstream, como um banco de dados.
- Verifique se há rebalanceamentos frequentes.
- Verifique se a taxa do produtor aumentou.
- Resolva com mais consumidores (até o número de partições), processamento mais rápido, processamento em lote ou mais partições.
16. Quando você deve aumentar o número de partições?
Quando você precisa de mais paralelismo do que os consumidores atuais conseguem oferecer, ou quando a taxa de transferência por partição é o limite. Cuidado: adicionar partições altera o mapeamento de chave para partição para novos registros, então a ordenação de uma chave pode quebrar durante a mudança. Planeje o número de partições desde o início quando a ordenação importa.
17. Como os dados são retidos, e o que é compactação de log?
Por padrão, o Kafka exclui segmentos antigos por tempo ou tamanho (retention.ms, retention.bytes). Com a compactação de log, o Kafka mantém pelo menos o valor mais recente de cada chave, o que é adequado para um changelog ou um tópico semelhante a uma tabela. Um valor nulo (um tombstone) marca uma chave para exclusão.
18. O que acontece se um broker falhar?
As partições lideradas por esse broker elegem novos líderes a partir do ISR. Os clientes atualizam os metadados e continuam. Se não houver réplica sincronizada disponível, a partição fica indisponível, a menos que você permita a eleição de líder não limpa, o que arrisca perda de dados.
19. Como você protege um cluster Kafka?
TLS para criptografia em trânsito, SASL (como SCRAM ou OAuth) ou TLS mútuo para autenticação, ACLs para autorização em tópicos e grupos, e controles de rede. Criptografe campos sensíveis no nível da aplicação, se necessário.
20. Como você monitora o Kafka?
Os principais sinais são lag do consumidor, partições sub-replicadas, partições offline, latência de requisições, uso de disco e taxas de redução e expansão do ISR, coletados por meio de métricas JMX e ferramentas como Prometheus e Grafana.
Perguntas de design
21. Quando você escolheria o Kafka em vez de uma fila de mensagens como RabbitMQ ou SQS?
Escolha o Kafka quando você precisa de alta taxa de transferência, reprocessamento de eventos passados, vários consumidores independentes do mesmo stream ou processamento de streams. Escolha uma fila tradicional para roteamento por mensagem, filas de tarefas simples ou quando você não quer gerenciar partições.
22. Projete um pipeline de eventos de pedidos.
"Os pedidos vão para um tópico orders com chave pelo ID do pedido, para que os eventos de um pedido permaneçam em ordem. Eu usaria três ou mais brokers, um fator de replicação de 3, acks=all e produtores idempotentes. Os consumidores de cobrança, estoque e análise usam cada um seu próprio grupo. As escritas de cobrança são idempotentes pelo ID do pedido, os registros com falha vão para um tópico de mensagens mortas, e eu monitoraria o lag por grupo. Eu escolheria o número de partições com base na taxa de transferência de pico e no número esperado de consumidores, com espaço para crescer."
Como se preparar
Se puder, rode um Kafka local, escreva um producer e um consumer group, pare um consumer e observe o rebalance. Quebre algo de propósito, como um consumer lento, e veja o lag. Prepare uma história real sobre um problema de pipeline de dados que você resolveu. Para tópicos relacionados, veja nossos guias de Databricks e entrevistas de system design.
Pratique explicar as garantias de entrega em voz alta, porque é aí que as respostas ficam vagas. Uma entrevista simulada e uma transcrição vão mostrar onde. Siga as regras da empresa sobre ferramentas de IA em qualquer entrevista ao vivo.
Pratique respostas de entrevista sobre Kafka com YesToTheOffer
Faça uma entrevista técnica simulada, explique as garantias de entrega em voz alta e revise sua transcrição depois. 30 minutos grátis, sem assinatura.
