# Arquitetura orientada a eventos Usar um único *pipeline* para realizar todas as tarefas do seu fluxo de integração pode parecer uma solução simples e eficiente, mas esse método pode trazer problemas a longo prazo. Aqui vamos falar sobre arquitetura orientada a eventos, um modelo mais eficiente que divide seu fluxo de integração em vários *pipelines*. ## O padrão publisher-subscriber Suponha que você fez uma compra com seu cartão de crédito. Após você fazer a transação, você recebe uma notificação do seu aplicativo do banco confirmando a compra e um e-mail da loja contendo a nota fiscal. Vamos usar esse exemplo para ilustrar a arquitetura orientada a eventos, conceito importante na arquitetura de *pipelines.* Alguns conceitos importantes desse modelo são: * **Evento**: uma ação de interesse de um sistema. No nosso exemplo, sua compra é um evento. * **Publisher (publicadores)**: a parte do sistema que informa quais eventos ocorreram. No nosso exemplo, a empresa de cartão de crédito é um *publisher*. Na Digibee Integration Platform, você pode publicar eventos com o componente [Event Publisher](/documentation/connectors-and-triggers/pt-br/connectors/queues-and-messaging/event-publisher.md). * **Subscriber ou consumer (inscrito ou consumidor)**: a parte do sistema que recebe informações acerca de certos eventos. No nosso exemplo, o aplicativo do banco e o e-mail da loja são *subscribers*. Na Digibee Integration Platform, você pode criar um *subscriber* com um [Event Trigger](/documentation/connectors-and-triggers/pt-br/triggers/messaging-and-events/event.md). No padrão **publisher-subscriber**, registros de eventos não são comunicados a *subscribers* específicos. Eles são enviados a um log administrado por um *event broker*, como o Apache Kafka ou o RabbitMQ. *Consumers* inscritos nesses eventos são informados quando eles ocorrem. Note que um único evento pode ser comunicado a vários *subscribers*. No nosso exemplo, o evento da compra foi comunicado tanto ao aplicativo do banco quanto ao e-mail da loja. Note também que *publishers* e *subscribers* não estão cientes uns dos outros e existem independentemente. Suponha que a loja não tenha e-mail e que o aplicativo do banco esteja fora do ar. Mesmo não havendo *subscribers* para o evento da compra, a empresa de cartão de crédito o publicaria de qualquer maneira. Na Digibee Integration Platform, você pode usar a arquitetura orientada a eventos para dividir seu fluxo de integração em mais de um *pipeline* e usar cada *pipeline* para um propósito específico. Esse modelo oferece várias vantagens, como: * **Evitar retrabalho**: suponha que você está construindo dez *pipelines*. Em cada *pipeline*, você quer fazer uma chamada a uma REST API de uma ferramenta ITSM sempre que um erro ocorre. Em vez de configurar o request em cada um dos dez *pipelines*, você pode criar um *pipeline* que faz essa chamada e usar [Event Publishers](/documentation/connectors-and-triggers/pt-br/connectors/queues-and-messaging/event-publisher.md) nos outros *pipelines* para ativá-lo. * **Facilitar manutenção**: suponha que você queira fazer um ajuste a essa parte do fluxo de integração responsável por enviar uma mensagem de erro a uma ferramenta ITSM. Em vez de ajustar dez *pipelines*, você pode ajustar somente a que faz a chamada API. * **Evitar erros**: usando um *pipeline* para cada tarefa, você reduz a chance de erros Out of Memory ou Timeout, causados por sobrecarga no *pipeline.* * **Escalar de acordo com sua necessidade**: usando a arquitetura orientada a eventos, você pode aumentar o tamanho de implementação somente dos *pipelines* do seu fluxo de integração que requerem mais memória, em vez de aumentar o de todos eles. ## Modelo síncrono {% hint style="success" %} Use o modelo síncrono para integrações que exigem confirmação imediata {% endhint %} {% hint style="danger" %} Não use o modelo síncrono para integrações que: * Manipulem grandes quantidades de dados * Insiram, modifiquem ou deletem dados em um banco de dados * Façam chamadas POST para serviços que não suportam grandes listas de dados * Demorem pra processar {% endhint %} Um dos modelos que usam arquitetura orientada a eventos na Digibee Integration Platform é o modelo síncrono. Nesse modelo, dividimos nosso fluxo de integração em dois tipos de *pipelines*: os ***pipelines***** de regra de negócio** e os ***pipelines***** de tratamento de erros**. Os ***pipelines***** de regra de negócio** realizam todos os passos necessários para fazer sua integração de dados. Quando um erro ocorre nesses processos, um componente Log os registra e um componente [Event Publisher](/documentation/connectors-and-triggers/pt-br/connectors/queues-and-messaging/event-publisher.md) publica o evento de erro. O ***pipeline***** de tratamento de erro** é um único pipeline que possui um *trigger* de evento. Ele “escuta” os eventos de erro que são publicados pelos *pipelines* de regra de negócio. Esse pipeline pode enviar alertas de erro ou reprocessar dados. Note que o mesmo evento de erro pode ser publicado por vários *pipelines* e enviado para o mesmo *pipeline* de tratamento de erro.

Modelo síncrono

## O modelo assíncrono {% hint style="success" %} Use o modelo assíncrono para integrações que: * Insiram dados em um banco de dados * Manipulem grandes quantidades de dados * Façam chamadas POST a serviços que não suportem grandes listas de dados * Demorem para processar {% endhint %} {% hint style="danger" %} Não use o modelo assíncrono para integrações que exigem confirmação imediata {% endhint %} Outro modelo que usa a arquitetura orientada a eventos é o modelo assíncrono. Para construir um fluxo de integração usando um modelo assíncrono, você deve construir quatro *pipelines:* **O primeiro pipeline** busca dados de um banco de dados ou de uma API e publica um evento para cada registro de dados. Se um erro ocorrer nesse processo, esse *pipeline* publica um evento de erro. **O segundo pipeline** é inscrito nos eventos publicados pelo primeiro *pipeline*. Ele recebe os registros de dados que foram buscados do banco de dados e os processa de acordo com a regra de negócio. Se um erro ocorrer durante esse processo, esse *pipeline* registra o erro, assim como o payload de input em um Object Store. **O terceiro pipeline** periodicamente acessa o Object Store mencionado anteriormente e busca registros de erros. Depois, ele checa quantas tentativas de reprocessamento já foram feitas para um determinado registro. Se o número de tentativas ainda não alcançou um limite definido anteriormente, o *pipeline* publica um evento de reprocessamento que será recebido pelo segundo *pipeline*. Se o número de tentativas de reprocessamento atingir o limite ou se um erro acontecer durante a execução desse *pipeline*, ele publica um evento de erro. **O quarto pipeline** é inscrito nos eventos de erro que foram enviados pelos três *pipelines* anteriores. Depois de receber esses eventos de erro, ele os armazena em um banco de dados e envia esses registros a uma ferramenta de ITSM ou por email.

Modelo assíncrono

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digibee.com/documentation/resources/pt-br/best-practices/event-oriented-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.