Kafka Avançado com Spring Boot: Retry, DLQ, Partitions e Escalabilidade
Muita gente aprende Kafka da forma errada.
Faz:
producer
consumer
envia mensagem
recebe mensagem
E acha que entendeu Kafka.
Mas em produção a história muda completamente.
Porque sistemas reais enfrentam:
falhas
mensagens inválidas
retries infinitos
perda de processamento
concorrência
alto volume
particionamento
reprocessamento
escalabilidade distribuída
E é exatamente aqui que começam os problemas.
O Kafka não é difícil apenas pela API.
Ele é difícil porque: event-driven architecture muda completamente a forma de pensar sistemas.
Neste guia vamos entrar na parte que realmente separa:
projetos simples
arquiteturas enterprise
Vamos abordar:
Retry
DLQ
Partitions
Consumer Groups
escalabilidade
performance
boas práticas
arquitetura real
projeto prático com Spring Boot
Tudo de forma prática.
O Que é Kafka de Verdade?
O Apache Kafka não é apenas um broker de mensagens.
Ele é uma plataforma distribuída de streaming de eventos.
Na prática: ele permite que sistemas troquem eventos de forma:
desacoplada
escalável
resiliente
distribuída
Por Que Kafka Cresceu Tanto?
Porque sistemas modernos precisam lidar com:
milhões de eventos
microsserviços
processamento assíncrono
escalabilidade horizontal
E soluções tradicionais começaram a sofrer.
Onde Kafka é Muito Utilizado?
Kafka domina principalmente:
bancos
fintechs
e-commerce
logística
marketplaces
streaming
ERPs
sistemas enterprise
Exemplo Real
Imagine um e-commerce.
Quando pedido é criado:
Pedido criado
↓
Evento enviado para Kafka
↓
Serviço de pagamento consome
↓
Serviço de estoque consome
↓
Serviço de e-mail consome
↓
Serviço de analytics consome
Tudo desacoplado.
Arquitetura Orientada a Eventos
Aqui está o ponto importante.
Kafka normalmente é usado em: Event-Driven Architecture.
Ou seja: sistemas passam a reagir eventos.
Isso reduz:
acoplamento
dependência síncrona
gargalos
Kafka com Spring Boot
O Spring possui integração excelente através do: Spring for Apache Kafka
Isso facilita:
producers
consumers
serialização
retry
DLQ
listeners
configuração enterprise
Dependência Maven
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>Producer Kafka
Exemplo simples:
@Service
@RequiredArgsConstructor
public class OrderProducer {
private final KafkaTemplate<String, String> kafkaTemplate;
public void send(String message) {
kafkaTemplate.send("orders-topic", message);
}
}Consumer Kafka
@Component
public class OrderConsumer {
@KafkaListener(topics = "orders-topic")
public void consume(String message) {
System.out.println(message);
}
}Até aqui: todo mundo conhece.
Agora começa a parte importante.
O Problema do Mundo Real
E se:
banco cair?
API externa falhar?
JSON vier inválido?
processamento quebrar?
serviço estiver fora?
Sem tratamento correto: o caos começa.
O Que é Retry no Kafka?
Retry é a tentativa automática de reprocessar mensagens com falha.
Isso é essencial porque: falhas temporárias acontecem o tempo inteiro.
Exemplo:
timeout
banco lento
API indisponível
rede
Problema do Retry Mal Feito
Muita gente faz retry infinito.
Resultado:
loop eterno
consumo travado
partição bloqueada
efeito cascata
Isso destrói sistemas.
Retry Correto no Spring Kafka
@RetryableTopic(
attempts = "3",
backoff = @Backoff(delay = 2000)
)
@KafkaListener(topics = "orders-topic")
public void consume(String message) {
processOrder(message);
}Aqui:
tenta 3 vezes
espera 2 segundos
Muito melhor.
O Que é DLQ?
DLQ significa: Dead Letter Queue.
Basicamente: mensagens que falharam definitivamente vão para uma fila separada.
Isso evita:
perda de mensagem
loop infinito
travamento
Fluxo Correto
Mensagem falha
↓
Retry executa
↓
Continua falhando
↓
Vai para DLQ
Perfeito.
Configurando DLQ
@Bean
public DeadLetterPublishingRecoverer recoverer(
KafkaTemplate<Object, Object> template) {
return new DeadLetterPublishingRecoverer(template);
}Por Que DLQ é Tão Importante?
Porque sistemas reais falham.
Sempre.
E ignorar isso é erro grave de arquitetura.
O Que São Partitions?
Partitions são divisões de um tópico Kafka.
Elas permitem:
paralelismo
distribuição
escalabilidade
Exemplo
Topic: orders-topic
Pode possuir:
partition 0
partition 1
partition 2
partition 3
Cada partição pode ser consumida separadamente.
O Grande Benefício das Partitions
Escalabilidade horizontal.
Mais consumers: mais processamento paralelo.
Consumer Groups
Consumer Groups permitem múltiplos consumidores trabalhando juntos.
Exemplo:
Consumer Group
Consumer A
Consumer B
Consumer C
Kafka distribui partitions automaticamente.
Regra Importante
1 partition
↓
Apenas 1 consumer daquela partition
Isso garante ordem.
Escalabilidade Real
Imagine:
10 partitions.
Você pode ter:
até 10 consumers processando paralelamente.
Isso é MUITO poderoso.
O Que Define a Chave da Partition?
Normalmente:
userId
orderId
accountId
Exemplo:
kafkaTemplate.send(
"orders-topic",
order.getUserId(),
objectMapper.writeValueAsString(order)
);Isso garante: eventos do mesmo usuário na mesma partition.
Ordem no Kafka
Outro ponto importante.
Kafka garante ordem:
apenas dentro da mesma partition.
Muita gente erra isso.
Kafka é Muito Rápido
Muito.
Porque foi criado para: alto throughput.
Grandes empresas processam:
milhões de eventos por segundo.
Boas Práticas de Performance
Evitar payload gigante
Mensagens muito grandes prejudicam throughput.
Usar compressão
Ajuda bastante.
Controlar retries
Retry errado destrói performance.
Configurar batch
Melhora throughput absurdamente.
Monitoramento é Obrigatório
Kafka sem observabilidade vira pesadelo.
Monitorar:
lag
throughput
retries
DLQ
consumers
é essencial.
Ferramentas Muito Utilizadas
Kafka UI
Kafka vs RabbitMQ
Item | Kafka | RabbitMQ |
|---|---|---|
Throughput | Excelente | Médio |
Escalabilidade | Excelente | Boa |
Streaming | Excelente | Limitado |
Ordem | Excelente | Boa |
Event Streaming | Excelente | Médio |
Complexidade | Alta | Média |
Quando Kafka Vale Muito a Pena?
Excelente para:
microsserviços
alto volume
processamento assíncrono
eventos distribuídos
analytics
sistemas financeiros
streaming
Quando Talvez Não Seja Necessário?
Para:
sistemas pequenos
baixa escala
pouca concorrência
Talvez seja exagero.
Kafka Não Resolve Arquitetura Ruim
Esse ponto é importante.
Kafka NÃO salva:
código ruim
arquitetura ruim
eventos mal definidos
acoplamento errado
Na verdade: Kafka pode piorar caos arquitetural.
O Erro Mais Comum em Kafka
Criar eventos demais.
Tudo vira evento.
Resultado:
rastreabilidade horrível
debugging difícil
arquitetura impossível de manter
Como Estruturar Eventos Corretamente?
Eventos precisam representar: algo importante de negócio.
Exemplo:
OrderCreated
PaymentApproved
UserRegistered
E não:
SaveButtonClicked
Projeto Prático Sugerido
Excelente projeto para estudo:
Sistema de pedidos
Serviços:
Order Service
Payment Service
Notification Service
Inventory Service
Fluxos:
retry
DLQ
partitions
consumer groups
observabilidade
Isso ensina MUITO.
Kafka em Arquiteturas Enterprise
Hoje Kafka virou praticamente padrão em:
fintechs
bancos
marketplaces
grandes plataformas
Porque resolve:
escala
desacoplamento
resiliência
Muito bem.
Vale a Pena Aprender Kafka em 2026?
Sim.
Muito.
Principalmente para backend Java.
Hoje Kafka virou uma das tecnologias mais valorizadas no mercado enterprise.
O Futuro do Kafka
Tudo indica crescimento ainda maior.
Principalmente com:
microsserviços
event-driven
streaming
IA em tempo real
analytics distribuído
Nossa Conclusão
Kafka não é apenas: “fila de mensagens”.
Ele muda completamente: a arquitetura do sistema.
Quando bem utilizado:
escala absurdamente
desacopla serviços
melhora resiliência
suporta alto volume
Mas exige:
arquitetura madura
observabilidade
tratamento de falhas
modelagem correta de eventos
Principalmente em sistemas enterprise modernos.