Sistemas distribuídos não são "difíceis demais" — eles são diferentes. As regras do mundo de processo único não se aplicam, e tentar forçá-las gera bugs que parecem mágicos.
O que você aprendeu
- Sistemas distribuídos — por que são diferentes, os oito enganos clássicos e os limites da rede.
- Comunicação síncrona vs assíncrona — quando usar HTTP/gRPC vs Kafka/SQS e Event-Driven Architecture.
- Kafka — brokers, topics, partições, producers, consumer groups e controle de offset.
- Conceitos críticos — consistência eventual, idempotência, retry exponencial e Dead Letter Queue.
- Problemas reais — perda de mensagem, duplicatas, ordem dos eventos: como cada um quebra em produção.
- Código Go com kafka-go — producer e consumer com at-least-once via
FetchMessage+CommitMessages. - Projeto guiado — dois serviços conectados via Kafka com retry, DLQ e docker-compose.
- Boas práticas — modelagem de eventos, schema versioning, configuração de topics e anti-patterns.
As três coisas que mais quebram na prática
- Não pensar em idempotência desde o dia 1. Vira bug em produção, sempre.
- Não desenhar pra falhas. Em sistemas distribuídos, falha é o estado normal — não a exceção.
- Achar que "ordem dos eventos" é automática. Não é. Você precisa garantir.
Kafka é uma ferramenta poderosa, mas o segredo não é Kafka.
O segredo é pensar em eventos, não em chamadas. Quando você internaliza isso, projeta sistemas que crescem sem virar bola de neve.
Bom estudo, e que suas mensagens sempre cheguem — pelo menos uma vez.