# Estratégia de reprocessamento em integrações orientadas a eventos O reprocessamento é essencial para manter a estabilidade das integrações. Este artigo explica como o reprocessamento de registros com falhas pode: * Prevenir a perda de dados. * Reduzir a intervenção manual. * Manter os sistemas funcionando de forma contínua. Entender o valor de um pipeline de reprocessamento ajuda a compreender como ele sustenta processos de integração eficientes e confiáveis. ## Reprocessamento em arquiteturas orientadas a eventos As **arquiteturas orientadas a eventos** (Event-Driven Architectures, EDA) permitem que os sistemas respondam dinamicamente a eventos em tempo real, acionando ações com base em **mensagens recebidas**. Para gerenciar esses eventos e melhorar o isolamento de tarefas, as integrações podem ser divididas em pipelines separados. Por exemplo, um pipeline principal pode ser responsável por ler registros, enquanto pipelines dedicados gerenciam o processamento, reprocessamento de eventos com falha e tratamento de erros. Em integrações orientadas a eventos, problemas temporários, como interrupções de rede ou indisponibilidade de serviços, podem interromper o processamento de mensagens. Esses erros geralmente são classificados como: * **Reprocessáveis (lado do servidor)**: Causados por problemas temporários. * **Não reprocessáveis (lado do cliente)**: Causados por payloads malformados ou dados de entrada incorretos. Sem uma **estratégia de reprocessamento**, esses erros aumentam os custos operacionais, criam ineficiências e exigem monitoramento constante para manter a integridade dos dados. Um pipeline de reprocessamento resolve isso enviando erros reprocessáveis de volta ao pipeline principal. ## Desafios do reprocessamento Não ter um mecanismo de reprocessamento pode levar a problemas significativos quando eventos falham devido a erros reprocessáveis, resultando em vários desafios importantes: * **Perda de dados**: Eventos que falham devido a erros temporários, como interrupções de rede ou indisponibilidade do sistema, podem ser descartados, resultando em perda crítica de dados e inconsistências. * **Intervenção manual**: Sem uma estratégia automatizada, eventos com falha exigem recuperação manual constante, aumentando a carga de trabalho das equipes de TI. * **Estados inconsistentes**: Quando eventos não são reprocessados, integrações podem resultar em estados inconsistentes. Isso acontece quando os sistemas mantêm dados conflitantes ou incompletos devido a eventos com falha que não foram tentados novamente, levando a dados conflitantes ou incompletos e à necessidade de correções manuais. Esses problemas não apenas afetam a satisfação do cliente, mas também aumentam solicitações de suporte, reembolsos e interrupções nos negócios. ## Colocando a teoria em prática Considere uma arquitetura de integração com múltiplos pipelines, cada um projetado para um propósito específico: um que consulta registros no banco de dados e publica eventos, outro que processa esses eventos individualmente, um terceiro que reprocessa os registros que falharam no pipeline de processamento e, por fim, um pipeline que gerencia o tratamento de erros. Nesse contexto, o **pipeline de reprocessamento** resolve o desafio de registros que **falham** em concluir seus processos devido a erros temporários e passíveis de nova tentativa, como problemas de rede ou indisponibilidade de serviços.
### Visão de alto nível em integrações orientadas a eventos Esse pipeline oferece uma solução para r**eprocessar eventos que falham na primeira tentativa** **de integração** porque ele repete automaticamente erros reprocessáveis por um **número configurado de tentativas**. Por exemplo, em uma integração onde pedidos de compra são enviados a um sistema de depósito, se o depósito estiver temporariamente indisponível, o pipeline de processamento salva o pedido com falha com um status de erro em um banco de dados de controle. Em intervalos programados, o pipeline de reprocessamento recupera esses registros e os envia de volta para a fila de processamento. Isso garante que os pedidos sejam reprocessados e enviados quando o sistema estiver disponível. Se um pedido ainda falhar após o número máximo de tentativas, ele é encaminhado para o pipeline de tratamento de erros para uma ação adicional. ### Como a solução proposta funciona
1. [Scheduler Trigger](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/triggers/scheduling/scheduler): O pipeline de reprocessamento inicia com um **scheduler** que o aciona em intervalos regulares. 2. **Recuperação de eventos com falha**: A cada intervalo, o pipeline verifica um banco de dados temporário para registros que não puderam ser processados pelo pipeline de processamento e os prepara para nova tentativa. 3. **Iterar registros da consulta**: Um conector de loop, como o [**For Each**](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/logic/for-each), para iterar por cada registro recuperado. Dentro do **Subfluxo OnProcess**, o primeiro passo é incrementar o contador de tentativas para rastrear o número de reprocessamentos realizados para o registro.
4. **Ramificação condicional**: Baseando-se no número de tentativas, o pipeline determina o próximo passo: * **Enviar para o pipeline de tratamento de erros**: Se o registro atingir o limite máximo de tentativas, ele é enviado para o pipeline de tratamento de erros para resolução adicional. É uma boa prática especificar o erro e notificar as partes interessadas sobre o limite atingido. * **Enviar para reprocessamento**: Se o registro não exceder o limite de tentativas, ele é enviado de volta ao pipeline de processamento para uma nova tentativa. Nessa abordagem, o pipeline usa o conector [Event Publisher](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/queues-and-messaging/event-publisher) para publicar cada registro de volta ao pipeline de processamento. Além disso, é possível usar outros conectores, como o [Pipeline Executor](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/pipeline-executor), que suporta comunicação assíncrona e síncrona, oferecendo maior flexibilidade para além do [Event Publisher](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/queues-and-messaging/event-publisher). 5. **Limpeza de registros**: Após o reprocessamento bem-sucedido ou o envio ao pipeline de tratamento de erros, o registro é removido do banco de dados temporário. Essa limpeza mantém o banco de dados eficiente e garante que nenhum dado desatualizado seja armazenado. O processo faz parte do ciclo de vida do evento e evita que o sistema seja sobrecarregado com registros antigos ou desnecessários. #### Conceitos-chave * **Banco de dados temporário**: Armazena temporariamente **registros com falha** até que sejam reprocessados ou atinjam o limite configurado de tentativas. * **Tentativas configuráveis**: O número de tentativas ajustado conforme a estratégia de reprocessamento, permitindo múltiplas tentativas se necessário. **A idempotência é crucial** para evitar processamento duplicado. * **Event Broker**: Facilita a comunicação roteando eventos de publicadores (conector [event publisher](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/queues-and-messaging/event-publisher)) para assinantes ([event trigger](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/triggers/messaging-and-events/event)), permitindo interações desacopladas e escaláveis no sistema. ## Benefícios do pipeline de reprocessamento 1. **Maior resiliência do sistema**: O pipeline melhora a resiliência ao reprocessar eventos que falharam devido a problemas no lado do servidor, garantindo que erros temporários sejam resolvidos e registros críticos preservados. 2. **Redução da intervenção manual**: Automatizando o reprocessamento de eventos com falha, o pipeline minimiza a necessidade de monitoramento manual e intervenção após cada falha. 3. **Uso eficiente de recursos**: Com limites configuráveis de tentativas, o pipeline otimiza a alocação de recursos, alinhando as tentativas às prioridades do negócio e à capacidade do sistema, reduzindo o risco de sobrecarga. 4. **Integração contínua com tratamento de erros**: Uma vez atingido o limite de tentativas, o pipeline envia o evento para um pipeline de tratamento de erros, garantindo que eventos não resolvidos sejam gerenciados sem interromper o fluxo geral do sistema. ## Considerações finais Em uma arquitetura orientada a eventos, **erros temporários são inevitáveis**. No entanto, o pipeline de reprocessamento garante que registros que falharam devido a erros no lado do servidor possam ser reprocessados sem interromper a integração. Ao gerenciar esses registros, o pipeline lida eficientemente com dados críticos e mantém a operação contínua de integrações orientadas a eventos. Para mais informações sobre o pipeline de reprocessamento, arquiteturas orientadas a eventos e estratégias para integrações escaláveis, explore nosso [Portal de Documentação](https://docs.digibee.com/documentation/pt-br), visite o [Digibee Academy](https://digibee.academy/courses/event-driven-arch-2) para cursos ou acesse nosso [Blog](https://www.digibee.com/blog/unleash-the-power-of-event-driven-integration/) para mais recursos e insights. Se você tiver feedback sobre este Caso Prático de Uso ou sugestões para futuros artigos, adoraríamos ouvir sua opinião. Compartilhe as suas ideias no nosso[ formulário de feedback](https://forms.gle/R84JfjbPVoVHGwZe9).