Skip to main content

Livro - Arquitetura Orientada a Eventos: Soluções escaláveis e em tempo real com EDA

  • Livro - Arquitetura Orientada a Eventos: Soluções escaláveis e em tempo real com EDA

alt text

O que é eventos e EDA?​

  • Eventos: No contexto EDA, representa um fato significante, uma mudança de estado; ele é imutável: uma vez que aconteceu, não pode ser desfeito
  • EDA: Arquitetura orientada a eventos (EDA) é um paradigma de design no qual um componente de software é executado em resposta ao recebimento de uma ou mais notificações de eventos. EDA é mais fracamente acoplado do que o paradigma cliente/servidor
info

Arquitetura orientada a eventos É um estilo arquitetural no qual aplicações ou microsserviços reagem a eventos em tempo real após alguma mudança de estado, em vez de responder a comandos

danger

NÃO use EDA para comunicar e gerenciar informações que devem ter consistência forte. Sua natureza distribuída e com comunicação assíncrona significa que seu sistema deve ser capaz de tolerar consistência eventual

Consistência eventual e forte​

  • Eventual: significa que os dados/informações após uma atualização serão eventualmente consistentes para todos os leitores. Aplicações podem ler o dado/informação inconsistente durante um certo período, isso é tolerável

  • Forte: significa que os dados/informações imediatamente após uma atualização serão consistentes para todos os leitores. Aplicações não podem ler o dado/informação inconsistentes, isso não é tolerado. Imagina o impacto em um sistema bancário onde aplicações diversas não leem o saldo correto do cliente logo após um saque

Benefícios​

  • Baixo acomplamento: as aplicações não precisam saber da existência uma das outras para trabalharem em conjunto

Desafios | Coreografia de eventos​

  • Uma solução EDA é composta por diversas aplicações que se comunicam através de eventos, formando uma cadeia de eventos para atingir um objetivo de negócio. A cadeia de eventos é conhecido como coreografia de eventos. As complexidas nesse paradigma são:

    • Comunicação assíncrona
    • Fluxo de compensação
    • Rastreabilidade da sequência de eventos
    • Governança dos eventos
    • Segurança
    • Versionamento dos eventos
    • Esquema de eventos
    • Testar a aplicação

Componentes chaves​

  • Produtor (event producer)
  • Broker: Broker de eventos, barramentos de eventos (event bus), roteador de eventos (event router) e hub de eventos (event hub)
  • Consumidor de eventos (event consumer)

O que é mensageria?​

  • Refere-se a tecnologia que permite que sistemas de computador compartilhem informações sem exigir conexões diretas ou conhecimento da localização uns dos outros

Destino da Mensagem​

  • Quando o evento é criado ele é endereçado a um destino (destination) ou canal (channel).O destino pode ser uma fila (queue) ou um tópico (topic)
    • Fila: significa que o evento pode ser consumido por no máximo uma aplicação consumidora
    • Tópico: significa que o vento pode ser consumido por mais de uma aplicação consumidora. Nos brokers de eventos com protocolo AMQP, as exchanges são consideradas um tipo de tópico

Semânticas de entrega​

info

Essas semânticas lidam principalmente com falhas (rede, crashes, duplicações) e impactam diretamente a confiabilidade e a lógica de consumo.

At most once (no máximo uma vez)​

  • A mensagem pode ser perdida, mas nunca será entregue mais de uma vez.
  • O broker envia a mensagem, mas não espera confirmação. Se houver falha, ela some.
  • Vantagem: baixa latência, simplicidade.
  • Desvantagem: risco de perda de mensagens.
  • Uso típico: métricas de telemetria, logs onde perda pontual é aceitável.

At least once (pelo menos uma vez)​

  • A mensagem será entregue uma ou mais vezes.
  • O broker exige confirmação do consumidor (ACK). Se não receber, reenviará.
  • Vantagem: não há perda de mensagens.
  • Desvantagem: pode haver duplicação, então o consumidor precisa ser idempotente (conseguir processar a mesma mensagem mais de uma vez sem efeitos colaterais).
  • Uso típico: processamento de pagamentos, filas de tarefas, integração entre sistemas.

Exactly once (exatamente uma vez)​

  • A mensagem é entregue uma única vez, sem perdas nem duplicações.
  • É o mais desejado, mas também o mais custoso em termos de implementação e desempenho.
  • Normalmente envolve transações distribuídas, commits de offsets ou protocolos de confirmação sofisticados.
  • Kafka, por exemplo, oferece essa semântica usando idempotência de produtores + transações.
  • Uso típico: cenários críticos, como transferências financeiras ou sistemas que não podem tolerar inconsistências.

Padrões de arquitetura para a arquitetura orientada a eventos​

Point-to-point(P2P)​

Definição: É um modelo de comunicação em que uma mensagem é enviada de um produtor para um único consumidor, usando uma fila (queue).

Como funciona:

  • O produtor coloca mensagens na fila.
  • Cada mensagem é entregue a apenas um consumidor.
  • Se houver vários consumidores na mesma fila, o broker distribui as mensagens entre eles (balanceamento de carga).

Vantagens:

  • Garantia de processamento único por mensagem.
  • Escalabilidade: múltiplos consumidores dividem o trabalho.
  • Produtor desacoplado do consumidor.

Desvantagens:

  • Não permite que múltiplos consumidores recebam a mesma mensagem.
  • Precisa de mecanismos de retry/DLQ em caso de falha no consumo.

Exemplo: Um serviço de pedidos envia mensagens para uma fila de processamento; cada pedido é consumido e tratado por apenas um worker.

Publish / Subscribe (Pub/Sub)​

Definição: É um modelo de comunicação baseado em eventos onde um produtor (publisher) envia mensagens para um tópico. Todos os consumidores (subscribers) interessados nesse tópico recebem a mesma mensagem.

Como funciona:

  • O produtor publica mensagens em um tópico.
  • Vários consumidores assinam esse tópico.
  • Cada mensagem publicada é entregue a todos os assinantes ativos.

Vantagens:

  • Permite broadcast de informações: vários sistemas podem reagir ao mesmo evento.
  • Produtor fica desacoplado dos consumidores (não precisa saber quem vai receber).
  • Escalável para cenários com múltiplos consumidores independentes.

Desvantagens:

  • Pode gerar duplicidade de processamento (cada subscriber processa a mesma mensagem).
  • Precisa de mecanismos de persistência se consumidores não puderem perder eventos.
  • Nem todos os brokers garantem ordenação ou entrega exatamente uma vez.

Exemplo: Um serviço de pagamentos publica o evento “Pagamento Aprovado” em um tópico:

  • O serviço de faturamento gera a nota fiscal.
  • O serviço de estoque separa o produto.
  • O serviço de notificações envia e-mail para o cliente. Todos recebem a mesma mensagem.

Event Streaming​

Definição: Modelo em que eventos são tratados como um log contínuo e ordenado, armazenados de forma durável e consumidos em tempo real. Cada consumidor mantém seu próprio offset, podendo ler em ritmos diferentes ou até reprocessar o histórico.

Características:

  • Eventos ficam registrados em um log.
  • Consumidores independentes controlam onde estão na leitura.
  • Permite reprocessamento e paralelismo massivo.

Request/Reply​

Definição: A comunicação no padrão request-reply refere-se a quando o produtor da mensagem precisa de uma resposta em algum momento no futuro. Nesse padrão, utilizamos dois canais point-to-point do tipo fila: uma para solicitação e outra para resposta

info

É ideal para casos onde o processamento da resposta pode levar bastante tempo, não bloqueando a aplicação produtora

Como funciona

  1. O cliente envia uma mensagem de requisição para uma fila ou tópico específico.
  2. Essa mensagem contém um Reply-To (endereço de resposta) e um Correlation ID (para identificar a resposta correta).
  3. O servidor processa a requisição e envia a resposta para a fila/tópico indicado no Reply-To.
  4. O cliente consome a resposta e usa o Correlation ID para casar com a requisição original.

Vantagens

  • Desacopla cliente e servidor, mantendo comunicação assíncrona.
  • Permite integração entre sistemas que exigem resposta, mas sem bloqueio direto (como RPC tradicional).

Desvantagens

  • Mais complexo que simples Pub/Sub ou Point-to-Point.
  • Pode introduzir overhead por precisar manter correlação e filas extras.
  • Em geral, se o caso de uso exige apenas notificação/eventos, pode ser desnecessário.

Exemplo prático

Um serviço de faturamento envia uma requisição para o serviço de estoque verificar disponibilidade de um item.

  • O pedido vai para a fila stock-check-requests.
  • O serviço de estoque processa e envia a resposta para a fila stock-check-replies.
  • O serviço de faturamento pega a resposta correspondente usando o Correlation ID.

Event Notification​

Definição: A comunicação no padrão event notification refere-se a quando o produtor envia apenas uma mensagem para avisar que algo aconteceu, sem carregar necessariamente todo o estado ou esperar resposta. É um estilo de integração assíncrona típico da arquitetura orientada a eventos.

warning

Carrega o mínimo de informações

Como funciona

  1. O produtor gera um evento descrevendo o que ocorreu (ex.: PedidoCriado).

  2. O evento é publicado em um broker/event bus (Kafka, RabbitMQ, SNS, etc.).

  3. Um ou mais consumidores se inscrevem nesse evento e reagem conforme sua necessidade.

    • Alguns podem apenas registrar logs.
    • Outros podem iniciar fluxos de negócio diferentes (ex.: disparar e-mail de confirmação).

Vantagens

  • Desacoplamento entre produtor e consumidores — o produtor não conhece seus assinantes.
  • Suporte natural a múltiplos consumidores reagindo ao mesmo evento.
  • Escalabilidade — o broker lida com alta taxa de eventos.

Desvantagens

  • Eventos geralmente não trazem todos os dados necessários → consumidores podem precisar buscar informações adicionais na fonte.
  • Garantias de entrega e ordenação podem variar conforme o broker.
  • Possível dificuldade de rastreabilidade de fluxos distribuídos.

Exemplo prático

Um sistema de pedidos publica o evento PedidoCriado.

  • O serviço de estoque consome o evento e reserva os itens.
  • O serviço de notificações envia um e-mail de confirmação ao cliente.
  • O serviço de analytics atualiza relatórios de vendas.

Event-Carried State Transfer​

Definição: A comunicação no padrão event-carried state transfer refere-se a quando o produtor envia o evento junto com o estado necessário para os consumidores agirem de forma independente, sem precisar consultar novamente a fonte. Ou seja, além de notificar, o evento carrega os dados relevantes.

Como funciona

  1. O produtor gera um evento descrevendo o que aconteceu, incluindo os dados necessários (ex.: PedidoCriado com itens, preços e dados do cliente).

  2. O evento é publicado em um broker/event bus.

  3. Cada consumidor recebe o evento e mantém seu próprio modelo de dados atualizado.

    • Um consumidor pode persistir em um banco otimizado para leitura.
    • Outro pode atualizar relatórios de analytics.
    • Outro pode disparar regras de negócio locais.

Vantagens

  • Consumidores ficam autônomos — não precisam buscar dados na origem.
  • Facilita CQRS e event sourcing com projeções locais.
  • Reduz acoplamento temporal (não depende da disponibilidade do produtor).

Desvantagens

  • Eventos ficam mais pesados (carregam mais dados).
  • Pode haver duplicação de informações entre sistemas.
  • Risco de inconsistência caso os dados enviados mudem depois (ex.: cliente atualiza endereço após evento já publicado).

Exemplo prático

Um sistema de pedidos publica o evento PedidoCriado com todos os detalhes do pedido:

  • O serviço de estoque recebe o evento e já reserva os itens localmente.
  • O serviço de faturamento calcula impostos e emite a fatura com base nos dados do pedido.
  • O serviço de analytics atualiza relatórios de vendas sem precisar consultar a base de pedidos.

Claim Check​

Definição: O padrão claim check refere-se a quando o produtor envia apenas uma referência (ID, URL, token) para o conteúdo completo, em vez de embutir o payload inteiro dentro do evento ou mensagem. O payload é armazenado em um repositório externo confiável (ex.: S3, banco de blobs, storage distribuído).

Como funciona

  1. O produtor recebe ou gera um payload pesado (ex.: fatura em PDF, imagem, documento XML).
  2. Ele armazena esse payload em um storage externo (banco de dados, storage de objetos, file server).
  3. Em vez de publicar o payload inteiro no broker, ele publica um evento curto contendo apenas a referência (Claim Check = “número da ficha”).
  4. O consumidor recebe o evento, lê a referência e recupera o payload completo diretamente do storage.

Vantagens

  • Mantém as mensagens leves e rápidas para trafegar no broker.
  • Evita limites de tamanho de mensagens (muitos brokers têm limites em KB/MB).
  • Útil para segurança — apenas consumidores autorizados podem buscar o payload real.

Desvantagens

  • Aumenta a complexidade: exige gestão de storage externo.
  • O consumidor precisa de dois passos (evento + busca do payload).
  • Pode gerar inconsistência se o payload for removido antes de todos os consumidores acessarem.

Exemplo prático

Um sistema de processamento de documentos fiscais gera notas em PDF:

  • O serviço de emissão publica um evento NotaFiscalGerada com apenas um Claim Check (ID ou URL segura).
  • O serviço de faturamento usa esse Claim Check para buscar o PDF completo no storage.
  • O serviço de auditoria também consome o evento e recupera a mesma nota para arquivamento.

Event Sourcing​

Definição: O padrão event sourcing refere-se a quando o estado de uma entidade não é armazenado diretamente em sua forma final, mas sim como uma sequência imutável de eventos que descrevem tudo o que aconteceu com ela. O estado atual é reconstruído ao reaplicar os eventos na ordem em que ocorreram.

info

O uso deste padrão é recomendado quando a solução tem requisitos de rastrear toda sequência de eventos de uma entidade de negócio, reverter alterações a partir de um ponto específico ou manter histórico e/ou registro de auditoria. Exemplo disso é o Git.

O Event sourcing só é possível quando utilizamos o padrão event-carried state transfer, pois precisamos aramazenar a sequência dos eventos com as informações completas da entidade de negócio

Como funciona

  1. Toda vez que ocorre uma mudança de estado, o sistema gera um evento (ex.: PedidoCriado, ItemAdicionado, PagamentoConfirmado).
  2. Esse evento é armazenado em um Event Store (banco especializado, log distribuído ou até Kafka).
  3. O estado atual de uma entidade é reconstituído ao reproduzir toda a sequência de eventos relacionados a ela.
  4. Serviços consumidores podem gerar projeções ou views materializadas para consultas rápidas, sem precisar reprocessar todos os eventos em tempo real.

Vantagens

  • Histórico completo de mudanças (auditoria nativa).
  • Permite reconstrução de estado em qualquer ponto do tempo.
  • Facilita a criação de projeções diversas (analytics, relatórios, CQRS).
  • Resiliência a mudanças de modelo de dados — basta reprojetar eventos antigos.

Desvantagens

  • Complexidade maior na implementação e no gerenciamento do Event Store.
  • Reconstituir o estado pode ser custoso se houver muitos eventos (precisa de snapshots).
  • Evolução de esquemas de eventos requer versionamento cuidadoso.

Exemplo prático

Um sistema de e-commerce usa Event Sourcing para gerenciar pedidos:

  • Evento PedidoCriado → registra que um pedido foi iniciado.
  • Evento ItemAdicionado → inclui um item ao pedido.
  • Evento PagamentoConfirmado → marca o pagamento como recebido.

Para saber o estado atual do pedido, o sistema reaplica todos os eventos em ordem. Ao mesmo tempo, um serviço de analytics gera relatórios de vendas a partir desses mesmos eventos.

CQRS (Command Query Responsibility Segregation)​

Definição:

O padrão CQRS (Command Query Responsibility Segregation) separa a responsabilidade entre operações de escrita (commands) e operações de leitura (queries) em um sistema. Enquanto o modelo de escrita lida com mudanças de estado (ex.: criar, atualizar, deletar), o modelo de leitura é otimizado para consultas rápidas e flexíveis.

info

Devemos usar quando a leitura de dados tem requisitos de desempenho e escabilidade

Como funciona

  1. O cliente envia um comando (ex.: CriarPedido) → que expressa a intenção de alterar o estado.
  2. O comando é validado e processado pelo modelo de escrita, que persiste a alteração no banco de escrita (ou gera eventos).
  3. Uma projeção ou processo de sincronização mantém atualizado o modelo de leitura.
  4. Quando o cliente deseja consultar (ex.: BuscarPedidos), ele acessa diretamente o modelo de leitura, já otimizado para consultas rápidas.

Vantagens

  • Permite escalabilidade independente: leitura e escrita podem ser otimizadas e escaladas separadamente.
  • Flexibilidade de consultas: o modelo de leitura pode ter estruturas específicas (ex.: views, índices, bancos NoSQL).
  • Clareza arquitetural: commands focam em regras de negócio, enquanto queries focam em atender ao cliente.
  • Naturalmente combina-se com Event Sourcing (commands geram eventos → projeções alimentam as queries).

Desvantagens

  • Complexidade maior na infraestrutura e sincronização entre modelos.
  • Possibilidade de consistência eventual (modelo de leitura pode atrasar em relação à escrita).
  • Requer mais esforço de design e manutenção, pois existem dois modelos separados.

Exemplo prático

No mesmo sistema de e-commerce:

  • O cliente envia um comando CriarPedido → o modelo de escrita valida regras de negócio e salva no banco de escrita.
  • Um processo de projeção atualiza o banco de leitura com os dados agregados.
  • Quando o cliente acessa a tela "Meus Pedidos", o sistema consulta diretamente o modelo de leitura otimizado para trazer a lista rapidamente, sem passar pelas regras de negócio.

SAGA Orquestrada e Coreografada​

info

SAGA é um padrão de arquitetura usado para lidar com transações distribuídas, principalmente em microserviços.

Uma SAGA é uma sequência de transações menores, executadas por serviços diferentes. Cada etapa confirma sua própria parte e, se alguma etapa falhar, as etapas anteriores são desfeitas por meio de ações de compensação.

SAGA orquestrada​

Na SAGA orquestrada, existe um orquestrador central responsável por controlar o fluxo da transação distribuída.

Ele decide:

  • qual serviço será chamado
  • em qual ordem as etapas acontecem
  • o que fazer em caso de sucesso
  • quais compensações executar em caso de falha

alt text

Esse modelo oferece maior visibilidade e controle do fluxo, pois a lógica principal fica concentrada em um único componente.

Como o orquestrador controla o estado da SAGA, normalmente é necessário manter uma máquina de estado para permitir recuperação em caso de falha.

EstadoSignificado
STARTEDSaga/processo iniciado.
PAYMENT_CREATEDPagamento criado.
BALANCE_RESERVEDSaldo reservado para a transação.
LEDGER_RECORDEDRegistro contábil/ledger gravado.
NOTIFICATION_SENTNotificação enviada com sucesso.
NOTIFICATION_PENDINGNotificação ainda pendente.
COMPLETEDSaga/processo concluído com sucesso.
CANCELLEDSaga/processo cancelado ou compensado.

Exemplo de fluxo orquestrado​

  1. Orquestrador chama Pagamento.autorizar().
  2. Orquestrador chama Estoque.reservar().
  3. Orquestrador chama Entrega.agendar().

Se Entrega falhar, o orquestrador executa compensações na ordem inversa:

  1. Estoque.cancelarReserva()
  2. Pagamento.estornar()

SAGA coreografada​

Na SAGA coreografada, não existe um coordenador central.

Cada serviço:

  • consome eventos de outros serviços
  • executa sua própria ação
  • publica novos eventos
  • reage a eventos de falha quando precisa compensar algo

alt text

Esse modelo favorece autonomia entre serviços, mas dificulta a visualização completa do fluxo, porque a lógica fica distribuída entre vários consumidores de eventos.

Exemplo de fluxo coreografado​

  1. PedidoCriado é publicado.
  2. Pagamento consome PedidoCriado, autoriza o pagamento e publica PagamentoAutorizado.
  3. Estoque consome PagamentoAutorizado, reserva o estoque e publica EstoqueReservado.
  4. Entrega consome EstoqueReservado, agenda a entrega e publica EntregaAgendada.

Se Entrega falhar:

  1. Entrega publica EntregaFalhou.
  2. Estoque consome EntregaFalhou e libera a reserva.
  3. Pagamento consome o evento de liberação/cancelamento e estorna o pagamento.

Comparativo​

CritérioSaga OrquestradaSaga Coreografada
CoordenaçãoCentralizada no orquestradorDistribuída entre os serviços
DebugMais fácilMais difícil
Visibilidade do fluxoAltaBaixa
EscalabilidadeMédiaAlta
AcoplamentoMaior acoplamento com o orquestradorMenor acoplamento direto entre serviços
Evolução do fluxoMais controladaMais arriscada se não houver governança de eventos
CompensaçõesMais previsíveisMais difíceis de rastrear
Complexidade operacionalConcentrada no orquestradorEspalhada pelos consumidores de eventos

Quando usar cada uma​

SituaçãoMelhor escolha
Fluxo críticoOrquestrada
Tem dinheiro envolvidoOrquestrada
Precisa controlar ordem, erro e compensação em um lugar centralOrquestrada
Time precisa debugar rápidoOrquestrada
Fluxo simples e naturalmente orientado a eventosCoreografada
Muitos serviços independentesCoreografada
Organização grande e descentralizadaCoreografada
Baixo acoplamento é mais importante que controle centralCoreografada

Vantagens e desvantagens​

TipoVantagensDesvantagens
OrquestradaMaior controle, melhor rastreabilidade, compensações mais previsíveisPode gerar acoplamento com o orquestrador e criar um ponto sensível no fluxo
CoreografadaServiços mais autônomos, maior desacoplamento e melhor elasticidadeFluxo disperso, debug mais difícil e maior risco de “spaghetti de eventos”

Boas práticas​

PráticaPor que usar
IdempotênciaEvita efeitos duplicados ao reprocessar comandos ou eventos.
Outbox PatternGarante publicação confiável de eventos junto com a alteração no banco.
Retries com backoffEvita sobrecarregar serviços em falhas temporárias.
Timeouts clarosImpede que uma SAGA fique presa indefinidamente.
Correlation ID / Saga IDPermite rastrear o fluxo ponta a ponta.
Dead Letter QueueIsola mensagens que não conseguiram ser processadas.
Compensações explícitasEvita tentar “apagar” efeitos que já aconteceram no mundo real.

Ferramentas típicas​

AbordagemFerramentas
OrquestraçãoTemporal, Camunda, Netflix Conductor, AWS Step Functions
CoreografiaKafka, RabbitMQ, SNS/SQS, EventBridge, contratos com Avro/JSON Schema

Change Data Capture (CDC)​

  • O CDC é um padrão que identifica e captura alterações no dado em tempo real, tipicamente em um banco de dados. Uma forma sofisticada de implementarmos o padrão CDC é usar outro padrão chamado Transaction log tailing

Transaction Log tailing​

  • Esse padrão transaction log tailing é o padrão que permite capturar as alterações de banco de dados pelo transaction log

Alguns bancos que possuem isso:

  • Oracle LogMiner
  • Mysql binlog
  • AWS DynamoDB Streams
  • SQL Server CDC
  • PostgresSQL write-ahead log

Webhook | Definição | Livro​

São notificações push baseadas em HTTP(s) acionadas quando um evento ocorre. Eles permitem que uma aplicação saiba que um evento ocorreu no sistema de origem.

Segurança | Livro​

Autorização | Access Control List (ACL), OPA (Open Policy Agent) | Livro​

Um dos mecanismos que existe é o Access Control List (ACL), onde podemos controlar o acesso no nível de topícos e filas, quais tópicos ou filas um determinado cliente pode publicar ou consumir; atribuir clientes a grupos ou diferenciá-los com base em suas funções.

Outro mecanismo é o OPA, que permite criamos uma política de segurança desagrupada do broker

Criptografia​

Para proteger os dados em trânsito na rede utiliza-se TLS (Transport Layer Security) também conhecido como TLS one-way (apenas o cliente valida se o broker é confiável). Outro modo também é o TLS two-way (tanto o cliente quanto o broker validam se são confiáveis), mas isso pode algum impacto no desempenho do fluxo de publicação e consumo de eventos, já que acaba sendo necessário criptografar e descriptografar tudo.

EventStorming | Hot Spot, Commands, Aggregates, Bounded Context | Livro​

  • É um workshop flexível e colaborativo que explora a complexidade do domínio de negócio, com técnicas de modelagem para identificar os eventos e/ou momentos de negócio a partir de um processo de negócio

  • Começa com a identificação de eventos de domínio

  • A pessoa facilitadora (quem conduz) tem a responsabilidade de fazer o merge de divergências e isso é conhecido como hot spot

  • O grupo adiciona commands ou triggers no quadro, que são ações que ativam eventos de domínio

  • Identificar agregados e agrupar em um contexto delimitado

    • Agredados (aggregates) e Contexto delimitado (bounded contexts)
      • Agregados: é um conjunto de entidades e objetos de valor que são tratados como uma unidade, definindo limites consistêntes dentro de um contexto delimitado

AsyncAPI​

É uma especificação para definir interfaces orientadas a eventos de maneira estruturada dentro da nossa solução de EDA. Ela é independente da linguagem de programação das aplicações produtoras e consumidoras, do broker de ventos e protocolos. AsyncAPI é para a EDA o que a OPENApi é para o REST API

CloudEvents​

  • É uma especificação para descrever dados de eventos em formatos comuns para fornecer interoperabilidade entre serviços, plataformas e sistemas.

Broker de eventos habilita a arquitetura orientada a eventos​

  • O broker de eventos é uma solução/software que atua como uma ponte entre o produtor do evento e o consumidor do evento. O broker de eventos tem um papel fundamental na EDA: é ele que garante o desacoplamento entre as aplicações com o seu modelo de publish-subscribe

Visibilidade do evento | pag. 188​

  • Após pegar o evento da fila, o broker mantém ele por um tempo fora do radar dos demais consumidores para que o mesmo evento não seja processado

Agendamento na entrega | Delayed events | pag. 191​

  • Aguns brokers possuem a capacidade de agendar a disponibilização de algum evento

Tipos de broker​

  • Orientado a fila (queue oriented)

    • Focam na comunicação desacoplada e assíncrona entre as aplicações através da fila
    • Features:
      • Preservar a ordem dos eventos (FIFO)
      • Dead-Letter queues (DLQ)
      • Point-to-Point
      • Publish-Subscribe
      • Request-reply
      • Agendamento da entrega do evento
      • Visibilidade do evento
      • Roteamento inteligente

  • Amazon SQS, Amazon MQ, Apache, ActiveMQ, Google Cloud Pub Sub, RabbitMQ ...

  • Orientado a log

    • Focam na ingestão eventos em série (stream) de forma contínua e não removem os eventos depois de confirmados pelas aplicações consumidoras
    • Features:
      • Event streaming
      • Publish-Subscribe
      • Retenção do evento
      • Reprodução do evento
      • Gerenciamento do esquema
      • Envio e recebimento de eventos em lote
      • Event Sourcing
      • Preservar ordem dos eventos (através de partição)

  • Kafka, Confluent, Azure Event Hub

  • Orientado a assinatura

    • Focam na distribuição de eventos baseados em regras de filtro utilizando o mecanismo de entrega push.
    • Features:
      • Publish-Subscribe
      • Webhooks
      • Roteamento inteligente
      • Mecanismo push
      • Agendamento da entrega do evento
      • Retentativa

  • Amazon SNS, Amazon EventBridge ...

Gerenciamento de API | API management | apim​

Essa plataforma de gerenciamento forneçe 3 componentes:

  • Gateway de API (API Gateway)

    • é o ponto de entrada de todas as request

  • Gerenciador de API (API Manager)

    • é aqui que você cria a API e lança

  • Portal do desenvolvedor (Developer Portal)

    • é um site personalizado para o cliente com toda a documentação das suas APIs

  • Nomes de APIM: Sensedia