Arquitetura event-driven em escala: decisões para produção

Arquitetura orientada a eventos não começa pela escolha de Kafka, RabbitMQ ou outro broker. Ela começa pela definição clara do fato de negócio que ocorreu, de quem é responsável por publicá-lo e de quais informações fazem parte de seu contrato.

Eventos devem ser compreensíveis fora do serviço que os produziu. Nome, versão, identificador, data de ocorrência e correlação ajudam consumidores a processar mensagens sem depender de detalhes internos do produtor.

Entregas duplicadas, mensagens fora de ordem e indisponibilidade temporária precisam ser tratadas como condições normais. Consumidores idempotentes, retentativas com limite e filas de mensagens não processadas evitam que uma falha localizada comprometa toda a operação.

Também é importante definir como eventos serão reprocessados e por quanto tempo ficarão disponíveis. Essa decisão afeta custo, recuperação de incidentes e capacidade de reconstruir estados derivados.

Contratos devem evoluir de forma compatível. Adicionar campos opcionais costuma ser mais seguro do que alterar significados existentes, e consumidores precisam tolerar informações que ainda não utilizam.

Métricas de atraso, taxa de erro, tamanho do backlog e tempo de processamento mostram a saúde real do fluxo. Com correlação entre logs e traces, o time consegue seguir uma transação entre serviços e agir antes que o atraso alcance o cliente.