Arquiteturas baseadas em Eventos (Event-Driven Architecture — EDA) e como implementá-las na AWS

Arquiteturas baseadas em eventos (Event-Driven Architecture, ou EDA) são um estilo de arquitetura de software em que os sistemas reagem a eventos em vez de chamadas de serviço tradicionais. Um “evento” pode ser qualquer alteração significativa de estado, como a criação de um novo registro em uma base de dados, a realização de uma transação financeira ou até mesmo uma ação do usuário em um site.

A principal diferença de uma arquitetura baseada em eventos em relação a uma arquitetura tradicional de microsserviços é que, ao invés de fazer chamadas diretas entre componentes, cada componente reage a eventos enviados por outros sistemas de forma assíncrona. Isso permite a construção de sistemas escaláveis, desacoplados e altamente responsivos.

Componentes principais de uma arquitetura baseada em Eventos

Uma arquitetura baseada em eventos é composta por vários elementos fundamentais que trabalham em conjunto para permitir a comunicação entre diferentes sistemas de maneira desacoplada e eficiente. Esses componentes desempenham papéis distintos no ciclo de vida de um evento, desde o momento em que ele é gerado até o seu processamento final. Vamos explorar cada um desses componentes de forma mais detalhada:

1. Emissor de Eventos (Event Producer)

O emissor de eventos é o ponto de origem de um evento. Ele é responsável por detectar uma mudança significativa de estado ou ação dentro de um sistema e, com base nisso, gerar um evento. A natureza da mudança pode variar bastante: pode ser a criação de um novo registro em um banco de dados, a atualização de um pedido de compra, a execução de uma transação financeira, ou até uma ação do usuário, como clicar em um botão em uma interface web.

Exemplo prático: Imagine um sistema de e-commerce onde o usuário finaliza uma compra. Nesse momento, o sistema de pedidos (emissor de eventos) gera um evento “Pedido Criado”, que será enviado para outros componentes interessados nesse evento, como o sistema de pagamentos ou de inventário.

O emissor de eventos não precisa saber quem irá consumir o evento ou o que será feito com ele. Sua responsabilidade é simplesmente publicar a ocorrência da ação.

2. Canal de Eventos (Event Channel)

O canal de eventos é o meio de transporte que conecta o emissor de eventos aos consumidores de eventos. Ele atua como um sistema de comunicação que garante que os eventos gerados cheguem aos seus destinos de forma confiável e eficiente. O canal de eventos pode assumir várias formas, dependendo da tecnologia utilizada. Entre os exemplos mais comuns estão:

• Filas de mensagens: Sistemas como o Amazon SQS permitem o armazenamento temporário de eventos, garantindo que os consumidores os processem quando estiverem prontos.
• Streams de dados: Serviços como Amazon Kinesis ou Apache Kafka são usados para transmitir grandes volumes de eventos em tempo real.

O canal de eventos é fundamental para garantir o desacoplamento entre os componentes, permitindo que emissores e consumidores funcionem de maneira independente, em tempos diferentes e em escalas variadas.

3. Consumidor de Eventos (Event Consumer)

O consumidor de eventos é o componente que recebe o evento enviado através do canal de eventos e o processa conforme a lógica de negócio definida. Um consumidor pode executar uma série de ações em resposta ao evento que ele recebeu. Dependendo do sistema, ele pode:

• Atualizar um banco de dados.
• Enviar uma notificação por e-mail.
• Executar uma chamada a uma API de terceiros.
• Acionar novos eventos como resposta.

Exemplo prático: Voltando ao exemplo do e-commerce, o sistema de inventário pode ser um consumidor de eventos. Assim que o evento “Pedido Criado” for recebido, ele pode ajustar a quantidade de produtos no estoque.

Os consumidores de eventos podem ser implementados como microsserviços, funções sem servidor (como o AWS Lambda) ou até aplicativos completos. Assim como os emissores, eles são completamente independentes, podendo ser escalados conforme necessário.

4. Processador de Eventos (Event Processor)

O processador de eventos é um componente especializado que recebe o evento e realiza ações de processamento, transformando os dados recebidos ou desencadeando novas operações. Embora o consumidor de eventos e o processador de eventos possam ser o mesmo componente em alguns casos, o processador geralmente é visto como um serviço que realiza manipulações mais complexas dos dados. Isso pode incluir:

• Transformação de dados: Alteração do formato dos dados para que estejam prontos para uso em outros sistemas.
• Filtragem de eventos: Ignorando eventos que não são relevantes ou aplicáveis.
• Orquestração de processos: Acionando outros eventos ou tarefas em sequência, conforme necessário.

Exemplo prático: No exemplo do e-commerce, o processador de eventos poderia ser um serviço que, ao receber o evento “Pedido Criado”, extrai informações sobre o cliente e transforma esses dados para que possam ser utilizados pelo sistema de CRM (Customer Relationship Management) para fins de marketing.

Implementação de Arquitetura Baseada em Eventos na AWS

A implementação de uma Arquitetura Baseada em Eventos (Event-Driven Architecture — EDA) na AWS é facilitada por uma ampla gama de serviços que oferecem suporte à comunicação assíncrona e escalável entre componentes. Um dos principais serviços utilizados para gerenciar eventos é o Amazon EventBridge, que atua como um barramento de eventos, permitindo que eventos sejam roteados de forma eficiente entre diferentes serviços e aplicações. Com ele, é possível configurar regras que definem como os eventos são distribuídos, garantindo que eles sejam processados pelos sistemas corretos. O Amazon SNS (Simple Notification Service) e o Amazon SQS (Simple Queue Service) oferecem modelos de mensagens publicados-subscrito e filas de mensagens para cenários onde é necessário desacoplar emissores e consumidores, proporcionando mais controle sobre o fluxo de eventos e garantindo alta disponibilidade.

A AWS também oferece serviços de processamento sem servidor, como o AWS Lambda, que permite a execução automática de código em resposta a eventos, sem a necessidade de provisionar ou gerenciar servidores. Lambda pode ser configurado para ser acionado por uma variedade de eventos, como mudanças em bancos de dados, atualizações em buckets do Amazon S3, ou até mesmo eventos gerados pelo Amazon EventBridge. Dessa forma, desenvolvedores podem se concentrar na lógica de negócio sem se preocupar com a infraestrutura subjacente. A combinação de Lambda com SNS, SQS ou EventBridge oferece uma solução escalável e eficiente para processar grandes volumes de eventos de forma distribuída.

Além do processamento de eventos em tempo real, a AWS também oferece soluções para armazenamento e análise de eventos históricos. Serviços como o Amazon Kinesis permitem a coleta, processamento e análise em tempo real de grandes fluxos de dados, enquanto o AWS Glue e o Amazon Athena facilitam a preparação e consulta de dados armazenados para gerar insights posteriores. Esses serviços permitem a construção de arquiteturas completas baseadas em eventos, cobrindo desde a geração e transporte de eventos, até o processamento e análise.

Cenário de Exemplo

Imagine que você tem um sistema de processamento de pedidos em que, após o cliente realizar um pedido, vários serviços precisam ser notificados, como o sistema de pagamento, inventário e notificação por e-mail. Uma arquitetura baseada em eventos poderia coordenar esses processos.

Arquitetura do Sistema

1. Emissor de Eventos

• O emissor de eventos será o serviço de criação de pedidos. Assim que um pedido é criado, um evento “Pedido Criado” será gerado.

2. Canal de Eventos

• O canal de eventos será gerido pelo Amazon EventBridge, que distribuirá eventos para os diferentes serviços interessados.

3. Consumidor de Eventos

Os consumidores serão:

• Sistema de Pagamento: Que processa o pagamento.
• Sistema de Inventário: Que verifica a disponibilidade do produto.
• Serviço de Notificação: Que envia um e-mail de confirmação ao cliente.

Arquitetura do Exemplo

1. O cliente faz um pedido.
2. O serviço de pedidos emite um evento “Pedido Criado” no Amazon EventBridge.
3. O Amazon EventBridge distribui esse evento para diferentes consumidores: Lambda para processar o pagamento, atualizar o inventário e enviar uma notificação por e-mail.

Agora, vamos implementar essa arquitetura usando Terraform para provisionar os recursos AWS.

1. Definindo o Amazon EventBridge

provider "aws" {
  region = "us-east-1"
}

resource "aws_cloudwatch_event_bus" "order_event_bus" {
  name = "order_event_bus"
}

2. Definindo a regra para o evento

resource “aws_cloudwatch_event_rule” “order_created_rule” {
 name = “order_created”
 event_bus_name = aws_cloudwatch_event_bus.order_event_bus.name
 event_pattern = <<PATTERN
{
 “source”: [“myapp.order”],
 “detail-type”: [“Order Created”]
}
PATTERN
}

3. Criando funções Lambda

resource “aws_lambda_function” “process_payment” {
 function_name = “process_payment”
 handler = “payment.handler”
 runtime = “nodejs14.x”
 role = aws_iam_role.lambda_exec.arn
 filename = “lambda_functions/payment.zip”
}

resource “aws_lambda_function” “update_inventory” {
 function_name = “update_inventory”
 handler = “inventory.handler”
 runtime = “nodejs14.x”
 role = aws_iam_role.lambda_exec.arn
 filename = “lambda_functions/inventory.zip”
}

resource “aws_lambda_function” “send_email” {
 function_name = “send_email”
 handler = “email.handler”
 runtime = “nodejs14.x”
 role = aws_iam_role.lambda_exec.arn
 filename = “lambda_functions/email.zip”
}

4. Criando destino da regra no Event-Bridge

resource “aws_cloudwatch_event_target” “payment_target” {
 rule = aws_cloudwatch_event_rule.order_created_rule.name
 target_id = “process_payment”
 arn = aws_lambda_function.process_payment.arn
}

resource “aws_cloudwatch_event_target” “inventory_target” {
 rule = aws_cloudwatch_event_rule.order_created_rule.name
 target_id = “update_inventory”
 arn = aws_lambda_function.update_inventory.arn
}

resource “aws_cloudwatch_event_target” “email_target” {
 rule = aws_cloudwatch_event_rule.order_created_rule.name
 target_id = “send_email”
 arn = aws_lambda_function.send_email.arn
}

1. Permissões para o Lambda receber eventos

resource “aws_lambda_permission” “allow_eventbridge_invocation_payment” {
 statement_id = “AllowExecutionFromEventBridge”
 action = “lambda:InvokeFunction”
 function_name = aws_lambda_function.process_payment.function_name
 principal = “events.amazonaws.com”
 source_arn = aws_cloudwatch_event_rule.order_created_rule.arn
}

resource “aws_lambda_permission” “allow_eventbridge_invocation_inventory” {
 statement_id = “AllowExecutionFromEventBridge”
 action = “lambda:InvokeFunction”
 function_name = aws_lambda_function.update_inventory.function_name
 principal = “events.amazonaws.com”
 source_arn = aws_cloudwatch_event_rule.order_created_rule.arn
}

resource “aws_lambda_permission” “allow_eventbridge_invocation_email” {
 statement_id = “AllowExecutionFromEventBridge”
 action = “lambda:InvokeFunction”
 function_name = aws_lambda_function.send_email.function_name
 principal = “events.amazonaws.com”
 source_arn = aws_cloudwatch_event_rule.order_created_rule.arn
}

Como pudemos ver, a implementação que fizemos em Terraform cria uma arquitetura baseada em eventos na AWS, utilizando Amazon EventBridge e funções AWS Lambda para processar os eventos. Essa abordagem permite uma solução escalável, resiliente e desacoplada, ideal para sistemas modernos que precisam responder a eventos em tempo real. A AWS oferece diversas ferramentas para facilitar o desenvolvimento de soluções baseadas em eventos, e serviços como SNS, SQS, EventBridge e Lambda desempenham papéis cruciais na criação de arquiteturas EDA eficientes.

Até o próximo post! =)