Trilha Arquitetura Orientada a Eventos: tudo o que estudar, tópico por tópico

Tratar um evento como um registro imutável de algo que aconteceu — a fonte única de verdade compartilhada entre serviços, em vez de um sinal transitório escondido atrás de uma API

A diferença entre um stream de eventos durável e reproduzível, do tipo log somente-acréscimo, e uma fila de mensagens tradicional, na qual mensagens são consumidas e removidas

Escolher entre mensagens finas de notificação de evento, que sinalizam uma mudança, e a transferência de estado carregada pelo evento, que inclui todos os dados de que o consumidor precisa

Modelar streams de eventos como tópicos: granularidade, a recomendação de uma entidade por tópico, propriedade de único escritor, e como os limites de tópico se alinham às entidades de negócio

O modelo produtor/consumidor: produtores escrevem em tópicos, consumidores leem no seu próprio ritmo via offsets, grupos de consumidores e o desacoplamento que isso cria entre os lados

Definir esquemas de eventos explícitos e serializáveis com Avro ou Protobuf, para que produtores e consumidores compartilhem um contrato fortemente tipado em vez de formatos JSON implícitos

Evoluir esquemas de eventos com segurança ao longo do tempo usando regras de compatibilidade retroativa, futura e total, para que produtores e consumidores antigos e novos coexistam

Tratar um stream de eventos publicado como um contrato de dados público de longa duração, com propriedade, semântica e garantias de qualidade explícitas das quais os consumidores podem depender

Usar um registro central de esquemas para armazenar, versionar e impor a compatibilidade dos esquemas de eventos, de modo que produtores não possam publicar mudanças incompatíveis

Processar cada evento de forma independente — transformações, filtros e enriquecimentos que não exigem memória de eventos anteriores e escalam horizontalmente com facilidade

Processamento que acumula estado entre eventos — agregações, junções, janelamento — apoiado por um armazenamento de estado local e um changelog para tolerância a falhas

Como chaves de partição determinam garantias de ordenação e paralelismo: eventos com a mesma chave permanecem ordenados dentro de uma partição, enquanto a ordenação entre partições não é garantida

Construir visões materializadas consultáveis consumindo um stream de eventos e mantendo uma tabela local que sempre reflete o estado mais recente para leituras rápidas

Persistir o estado como um log ordenado de eventos de domínio em vez de linhas atuais, reconstruindo o estado por meio do replay dos eventos e habilitando auditoria histórica completa

Command Query Responsibility Segregation: separar o modelo de escrita, que valida e emite eventos, dos modelos de leitura otimizados de forma independente e construídos a partir desses eventos

Escrever atomicamente o estado de negócio e uma linha de evento na outbox em uma única transação local, e então repassar as linhas da outbox para o stream de eventos, evitando a inconsistência da escrita dupla

Construir e reconstruir projeções do lado de leitura dobrando eventos em visões dedicadas, e reproduzir desde o início para recriar uma projeção após uma mudança de modelo

Coordenar fluxos de trabalho entre múltiplos serviços reagindo a eventos (coreografia) versus um coordenador central emitindo comandos (orquestração), e os trade-offs de cada abordagem

Gerenciar uma transação distribuída de longa duração como uma sequência de transações locais, cada uma publicando um evento que dispara o próximo passo ou uma ação de compensação em caso de falha

Projetar transações de compensação que desfazem semanticamente passos concluídos de uma saga quando um passo posterior falha, já que transações locais commitadas não podem sofrer rollback

Raciocinar sobre as semânticas no-máximo-uma-vez, no-mínimo-uma-vez e exatamente-uma-vez, e por que a entrega no-mínimo-uma-vez somada a consumidores idempotentes é o caminho pragmático para o processamento efetivamente-uma-vez

Tornar consumidores seguros sob entrega duplicada e fora de ordem usando chaves de idempotência, deduplicação e semântica de upsert, de modo que o reprocessamento não cause desvio de efeitos colaterais

Isolar mensagens envenenadas que falham repetidamente no processamento em um stream de dead-letter, para que não bloqueiem a partição, além de estratégia de retentativa, alertas e reprocessamento

Aceitar que o estado derivado entre serviços converge ao longo do tempo, raciocinar sobre atraso de replicação e anomalias de leitura-das-próprias-escritas, e projetar UX e APIs que as tolerem

Explorar streams de eventos duráveis para reproduzir o histórico — preenchendo novos consumidores, reconstruindo estado após bugs e inicializando novos serviços a partir do log retido