Resolva os exercícios na ordem — cada nível aprofunda o anterior. Tente resolver sem consultar a solução.
Nível 1 — Iniciante
1. Setup local do Kafka. Configure um Kafka local com Docker e crie um topic usuarios com 3 partições. Liste os topics existentes via CLI.
2. Producer com keys. Escreva um producer que publique 10 mensagens com keys diferentes (user-1 a user-10). Use kafka-console-consumer para verificar em quais partições cada uma caiu.
3. Partições por key. Modifique o exercício 2 para que todas as mensagens tenham a mesma key (user-1). Confirme que todas caíram na mesma partição.
Nível 2 — Intermediário
4. Consumer em Go. Implemente um consumer em Go que:
- Lê do topic
usuarios. - Imprime
partition,offset,keyevaluede cada mensagem. - Comita offset apenas após processar com sucesso.
5. Balanceamento de partições. Suba dois consumers no mesmo group. Veja como as partições são divididas entre eles. Mate um e observe o rebalanceamento.
6. Consumer groups independentes. Suba dois consumers em groups diferentes. Confirme que ambos recebem todas as mensagens.
7. Idempotência na prática. Crie um consumer não-idempotente (ex: que incrementa um contador num arquivo). Force uma duplicação (mate ele logo após processar mas antes de comitar). Observe o estrago. Depois, refatore pra ser idempotente.
Nível 3 — Avançado
8. Projeto do zero. Implemente o projeto guiado do capítulo anterior do zero, sem olhar o código. Adicione:
- Validação de payload com retorno de erro estruturado.
- Métricas Prometheus expostas em
/metrics(mensagens processadas, erros, tempo de processamento). - Health check em
/health.
9. Retry topics em cadeia. Implemente uma chain de retry topics: ao falhar, em vez de retentar em memória, jogue a mensagem em orders.retry.5s, orders.retry.30s, orders.retry.5m, e finalmente em orders.dlq. Cada topic de retry tem um consumer próprio que aguarda o tempo configurado antes de tentar republicar no topic original.
10. Outbox Pattern. Implemente o Outbox Pattern: o serviço A grava o pedido no banco e, na mesma transação, grava o evento numa tabela outbox. Um worker separado lê da outbox e publica no Kafka. Por que isso é melhor que publicar direto no Kafka dentro do handler HTTP? (Pista: o que acontece se o Kafka estiver fora no momento do request?)
Desafios de Raciocínio
Desafio 1. Você tem 1 topic com 3 partições. Quantos consumers no mesmo group fazem sentido? E se forem 5 consumers? E se forem 2?
Desafio 2. Um colega diz: "vou usar Kafka pra fazer requisição síncrona — publico no topic A e fico ouvindo o topic B esperando a resposta". Cite 3 motivos pelos quais isso é uma péssima ideia.
Desafio 3. Sua DLQ está com 50 mil mensagens. Como você investigaria? Em que ordem você as reprocessaria? O que faria se 80% delas fossem da mesma causa raiz já corrigida?
Desafio 4. O time de produto pede: "queremos saber em tempo real quantos pedidos foram feitos por minuto". Como você implementaria? (Pesquise: Kafka Streams, ksqlDB, ou um consumer customizado?)