Quando Kafka Vira Bengala Arquitetural
O erro clássico: achar que Kafka é cura universal para escalabilidade. **Muita gente coloca Kafka onde só precisava de um simples “retry” assíncrono**. Resultado? Over-engineering e mais uma stack que ninguém no time sabe operar.
O hype de que Kafka = resiliência cria a falsa sensação de que microserviços ficam “intocáveis”. Só que resiliência não nasce do broker — nasce do design. Se o serviço é podre, Kafka só empacota essa podridão em eventos bonitos.
Kafka Resolve? Resolve. Mas Só se o Problema For Dele.
A solução pragmática: use Kafka quando você precisa de throughput alto, eventos imutáveis, reprocessamento e pipelines de dados. Não para RPC glorificado ou como substituto de comunicação entre microserviços que só precisam responder rápido.
Quer resiliência real? Circuit breaker, idempotência e design orientado ao domínio. Kafka entra quando o domínio pede streaming, não quando o time quer parecer “cloud native”.
Implementação de Sênior: Processamento Idempotente com Kafka
Vamos ao que importa: código que evita tragédias. Consumidor Kafka com idempotência real usando chave de negócio + store simples.
using Confluent.Kafka;
using Dapper;
using Npgsql;
var config = new ConsumerConfig {
GroupId = "pedido-processador",
BootstrapServers = "kafka:9092",
AutoOffsetReset = AutoOffsetReset.Earliest
};
using var consumer = new ConsumerBuilder<string, string>(config).Build();
consumer.Subscribe("pedido-criado");
while (true)
{
var cr = consumer.Consume();
var idEvento = cr.Message.Key;
using var conn = new NpgsqlConnection(envConnString);
// Bloqueia repetição de evento
var exists = await conn.ExecuteScalarAsync<bool>(
"select exists (select 1 from eventos_processados where id = @id)",
new { id = idEvento }
);
if (exists) continue;
// Processa pedido
var payload = JsonSerializer.Deserialize<PedidoCriado>(cr.Message.Value);
await ProcessarPedido(payload);
// Marca como processado
await conn.ExecuteAsync(
"insert into eventos_processados (id) values (@id)",
new { id = idEvento }
);
}
Simples, direto e evita o clássico bug de processar o mesmo evento três vezes em horário de pico.
O Custo da Escolha: Onde Kafka Brilha e Onde Ele Te Derruba
**Kafka é excelente onde produção de eventos é massiva. É péssimo quando sua necessidade é resposta síncrona.**
- Você ganha reprocessamento, mas perde simplicidade operacional.
- Você ganha throughput, mas paga com infraestrutura pesada.
- Você ganha distribuição, mas complica debugging.
Se o problema é comunicação entre microserviços, muitas vezes um simples RabbitMQ — bem configurado — resolve com menos drama.
Direto das Trincheiras
- Kafka não é fila. Não tente usá-lo como RabbitMQ de grife.
- Seu microserviço não fica resiliente só porque está atrás de um tópico.
- Se você não sabe operar Kafka em produção, você não está pronto para usá-lo.
Fontes
Kafka vs PubSub do ponto de vista gerencial : r/ExperiencedDevs,
Kafka vs RabbitMQ | gaGO.io,
‘Não use um banco de dados como uma fila’ : r/dotnet
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
