Microsserviços resolveram um problema gigante: o fim dos monolítos quebradiços. Mas criaram outro – o acoplamento implícito. Quando o Serviço A precisa chamar o Serviço B que chama o C, você trocou um acoplamento de código por um acoplamento de rede. E pior: se B cai, A também quebra.
É aí que entra a Arquitetura Orientada a Eventos (Event-Driven Architecture – EDA). Ela não substitui microsserviços – ela os potencializa, tornando o sistema verdadeiramente desacoplado, resiliente e escalável.
Neste post, vamos mostrar como Go se torna a linguagem perfeita para construir sistemas orientados a eventos, e por que esse é o próximo passo natural para empresas que já dominam microsserviços.
O problema que microsserviços não contaram
No modelo síncrono tradicional (REST, gRPC), um serviço chama outro e espera a resposta. Isso parece simples, mas em escala:
- Latência acumulada: uma cadeia de 5 serviços pode levar segundos.
- Falhas em cascata: se um serviço morre, todos que dependem dele também param.
- Acoplamento temporal: o emissor e o receptor precisam estar vivos ao mesmo tempo.
- Dificuldade de evolução: mudar um contrato exige coordenar vários times.
Microsserviços sozinhos não resolvem isso. Eles só trocam um monólito por uma coreografia frágil.
A virada: eventos como primeira classe
A arquitetura orientada a eventos inverte a lógica. Em vez de chamar serviços diretamente, os serviços publicam eventos (“PedidoCriado”, “PagamentoAprovado”) em um broker de mensagens (Kafka, RabbitMQ, NATS, etc.). Outros serviços consomem esses eventos quando podem, no seu próprio ritmo.
Vantagens imediatas:
- Desacoplamento total: A não sabe quem consome seus eventos.
- Resiliência: Se B cair, o evento fica no broker até ele voltar.
- Escala independente: cada serviço escala conforme sua carga.
- Replay histórico: você pode reprocessar eventos passados.
Por que Go é a linguagem dos sistemas orientados a eventos
Go foi construída para concorrência e I/O – exatamente o que um sistema orientado a eventos exige.
1. Goroutines para consumidores massivos
Cada evento pode ser processado em uma goroutine separada. Você pode consumir 100 mil eventos por segundo sem suar.
for msg := range consumer.Messages() {
go processEvent(msg) // cada evento em sua goroutine
}2. Canais (channels) como brokers em memória
Para testes ou sistemas menores, os próprios canais do Go funcionam como um broker leve e tipado.
3. Clientes maduros para os principais brokers
- Kafka:
segmentio/kafka-go,confluent-kafka-go - NATS: cliente oficial excelente (
nats.go) - RabbitMQ:
streadway/amqp - Redis Pub/Sub:
go-redis
4. Performance bruta
O binário estático e a baixa latência do Go fazem com que o overhead do broker seja o gargalo – não seu código.
5. Serialização eficiente
Go lida muito bem com JSON (rápido o suficiente para maioria), mas também tem suporte nativo a protobuf e msgpack para cenários de ultra performance.
Padrões que funcionam em Go
1. Event Sourcing
Cada mudança de estado é armazenada como um evento imutável. Para reconstruir o estado atual, você reproduz todos os eventos. Go é ótimo para isso porque a tipagem forte evita inconsistências.
2. CQRS (Command Query Responsibility Segregation)
Separa operações de escrita (command) e leitura (query). Eventos são usados para atualizar as views de leitura. Em Go, você pode ter handlers concorrentes para cada tipo de evento.
3. Saga Coreografada
Transações distribuídas sem locks. Cada serviço publica eventos de sucesso ou falha, e outros serviços reagem com ações compensatórias. Go permite implementar essas sagas de forma limpa com canais e context.
Caso concreto: e-commerce com eventos em Go
Imagine um e-commerce onde, ao criar um pedido:
- Serviço de Pedidos publica
PedidoCriado - Serviço de Estoque consome e reserva produtos → publica
EstoqueReservadoouEstoqueInsuficiente - Serviço de Pagamento consome e processa → publica
PagamentoAprovado - Serviço de Notificação consome e envia e-mail/SMS
- Serviço de Logística consome e agenda a entrega
Cada serviço é escrito em Go. Se o serviço de notificação cair, ninguém para. Quando voltar, consome os eventos pendentes do Kafka. A experiência do cliente não é afetada.
Quando NÃO usar eventos?
EDA não é bala de prata. Evite em:
- Sistemas que exigem consistência forte e imediata (ex: transferência bancária intrabanco). Aí vai de transações distribuídas ou saga com compensação.
- Sistemas muito pequenos – o overhead do broker não compensa.
- Times imaturos – eventos exigem disciplina de versionamento e monitoramento.
Para tudo que precisa escalar e ser resiliente, EDA é o caminho.
Como a Jacobus implementa EDA com Go
Nos projetos da Jacobus, usamos NATS para baixa latência (mensagens entregues em <1ms) e Kafka para retenção longa e replay. Tudo em Go.
Nossa abordagem:
- Cada microsserviço Go publica e consome eventos de forma tipada (com protobuf).
- Usamos outbox pattern para garantir que eventos sejam publicados mesmo com falhas – o evento é salvo no banco junto com a transação, e um worker Go o envia de forma confiável.
- Monitoramos lag de consumidores com Prometheus + Grafana.
- Fazemos deploy canário de novos consumidores sem medo.
Resultado: sistemas que resistem a picos de black friday, a falhas de serviços e a mudanças de regras de negócio sem parar.
Conclusão: microsserviços não bastam. Adicione eventos.
Se você já tem microsserviços, provavelmente já sentiu a dor do acoplamento síncrono. Arquitetura orientada a eventos é o antídoto. E Go, com sua concorrência nativa, canais e ecossistema maduro, é a ferramenta certa para construir sistemas reativos, resilientes e verdadeiramente escaláveis.
Na Jacobus Software, transformamos arquiteturas frágeis em sistemas orientados a eventos que crescem com o negócio. Seu próximo passo começa aqui.
📡 Quer desacoplar seus microsserviços de vez?
Nossos especialistas projetam e implementam arquiteturas orientadas a eventos em Go, com Kafka, NATS ou RabbitMQ – garantindo resiliência e escala para seu negócio.