Apache Kafka tornou-se a espinha dorsal de muitos sistemas de dados modernos — e por boas razões. É um log distribuído imutável, durável e de alta performance. Mas a diferença entre usar Kafka correctamente e usar Kafka de forma problemática está nos detalhes que os tutoriais introdutórios raramente cobrem.
O modelo fundamental: log imutável
Kafka não é uma queue de mensagens tradicional. É um log de eventos ordenado por tempo, dividido em partições, replicado entre brokers. Esta distinção importa: eventos não são apagados quando consumidos — ficam retidos pelo período configurado (por defeito, 7 dias). Isto permite múltiplos consumers independentes a processar os mesmos eventos, e reprocessamento histórico quando necessário.
Partições e paralelismo
O nível de paralelismo de um consumer group é limitado pelo número de partições do tópico. Se tens um tópico com 8 partições e um consumer group com 3 instâncias, duas instâncias ficam com 3 partições e uma fica com 2. Se tens 10 instâncias e 8 partições, 2 instâncias ficam ociosas.
Escolher o número de partições é uma decisão de design importante: mais partições permitem maior paralelismo mas aumentam a overhead de metadata no cluster. Uma regra prática: começa com um número que seja múltiplo dos teus consumers esperados, e evita aumentar partições depois de criado o tópico sem considerar o impacto no ordering.
Garantias de entrega
Kafka oferece três modos de entrega:
- At-most-once: mensagens podem perder-se, nunca duplicadas. Útil para métricas não-críticas.
- At-least-once: mensagens nunca perdem, podem duplicar. O modo mais comum — exige idempotência no consumer.
- Exactly-once: garantia forte via transactions. Performance mais baixa, complexidade mais alta.
Na prática, a maioria dos sistemas usa at-least-once com consumers idempotentes — é o melhor compromisso entre performance e correctude.
Consumer lag — o indicador mais importante
O consumer lag (diferença entre o offset do último evento produzido e o offset do último evento consumido) é o indicador de saúde mais importante de um pipeline Kafka. Um lag crescente significa que os consumers não acompanham a produção.
Monitoriza sempre: lag por consumer group e por partição, throughput de produção vs consumo, e tempo de retenção disponível. Se o lag ultrapassar o período de retenção, perdes eventos — um cenário catastrófico que é totalmente evitável com alertas adequados.
Schema Registry — um must em produção
Em ambientes com múltiplas equipas a produzir e consumir eventos, o Schema Registry (Confluent ou Apicurio) é indispensável. Define o contrato de cada tópico em Avro ou Protobuf, versiona os schemas, e permite evolução de schema com compatibilidade garantida. Sem isto, uma mudança de estrutura num evento pode quebrar silenciosamente todos os consumers.