Instabilidade no Processamento de Eventos Assíncronos - Webhook

Update timeline

1. resolved May 07, 2026, 02:19 PM UTC

   Resumo Executivo e Impacto Identificamos uma intercorrência em nossa plataforma entre 10:07am e 10:14am, resultando em um atraso no processamento de filas assíncronas e no envio de notificações de saída (webhooks). Durante este intervalo de 7 minutos, o sistema apresentou latência na entrega de eventos, afetando a execução de fluxos em tempo real. O impacto deu-se para uma parcela mínima de clientes. Reiteramos que não houve perda de dados; todas as notificações acumuladas foram processadas e entregues integralmente após a estabilização do componente. Clientes que não identificaram elevação no tempo de resposta em seus logs de integração durante este período específico não foram afetados. Causa Raiz e Resolução A causa raiz foi uma falha em um componente de infraestrutura responsável pela gestão de mensagens e eventos assíncronos. Esta instabilidade causou o reinício (restart) automático do serviço, interrompendo momentaneamente a vazão das filas. A resolução ocorreu de forma automática através dos mecanismos de autorrecuperação da nossa camada de infraestrutura, que restabeleceu o serviço e permitiu o escoamento das tarefas represadas até que o processamento voltasse ao estado de normalidade. Compromisso e Próximos Passos Estamos comprometidos com a alta disponibilidade de nossos serviços. Como ação imediata, nossa equipe de SRE e Integrações iniciou a revisão das métricas de monitoramento e a criação de novos indicadores de nível de serviço (SLO) para garantir maior previsibilidade e robustez neste componente. Um Postmortem detalhado com a análise técnica profunda e o plano de mitigação de longo prazo será compartilhado em breve. Pedimos desculpas profissionalmente pelo transtorno causado à sua operação. Equipe Unico.

2. postmortem Jun 09, 2026, 07:03 PM UTC

   **Resumo** Em 07 de maio de 2026, entre 10h07 e 10h14 \(horário de Brasília\), o processamento assíncrono do serviço de criação de processos ficou interrompido por aproximadamente 7 minutos. O incidente foi causado pelo reinício inesperado do componente de captura de eventos de banco de dados, que é responsável por encaminhar eventos para as filas de notificação via webhook. Após a recuperação, houve um pico de reprocessamento do acúmulo de mensagens — o volume saltou de ~2 mil para ~18,8 mil transações antes de se estabilizar. O incidente foi registrado como parte de uma série de eventos recorrentes que aceleraram a decisão de substituir a arquitetura de entrega de webhooks. **Impacto** Todos os usuários de clientes que dependem de notificações via webhook para continuidade de seus fluxos de negócio foram impactados. Durante os 7 minutos de interrupção, nenhum evento foi entregue em tempo real. Após a recuperação do componente, o backlog acumulado foi processado com um pico de carga significativo. O padrão de impacto foi idêntico ao registrado no dia anterior, afetando os mesmos clientes. **Causa Raiz** A causa raiz foi uma falha de saturação na cadeia de entrega de mensagens. O componente de captura de eventos reiniciou de forma inesperada, interrompendo completamente o fluxo de eventos assíncronos. A arquitetura dependia de uma cadeia com múltiplos saltos entre sistemas — banco de dados, conector de captura, sistema de filas e serviço de notificação — sem nenhuma rota alternativa ou mecanismo de recuperação automática. A ausência de redundância fez com que o reinício de um único componente paralisasse a entrega de webhooks para todos os usuários simultaneamente. O problema era conhecido e uma substituição arquitetural estava em andamento, mas ainda não havia sido concluída no momento do incidente. **Resolução** O componente se recuperou automaticamente após o reinício e processou o backlog acumulado. A equipe acelerou a implantação de um novo mecanismo de entrega de webhooks, que foi ativado a 100% do tráfego em 08/05 às 07h20. Nos dias seguintes, o novo mecanismo processou mais de 6 milhões de webhooks com apenas 3 erros isolados e transitórios. ‌ **Lições Aprendidas** * A cadeia de infraestrutura de entrega de webhooks possuía um ponto único de falha: o reinício de um único componente era suficiente para interromper a entrega para todos os usuários. A migração para uma rota direta eliminou esse risco estrutural. * Os alertas de monitoramento estavam configurados com janelas de 5 minutos e severidade baixa, inadequados para um fluxo transacional onde atrasos de 1-2 minutos já geram impacto nos usuários. As janelas foram reduzidas para 2 minutos após o incidente. * O novo mecanismo de entrega adotado é do tipo "disparar e esquecer", sem lógica de reenvio em caso de falha. Isso significa que falhas transitórias no serviço de destino podem resultar em perda definitiva de mensagens — o que exige mecanismos compensatórios de reenvio com backoff exponencial. * A documentação para usuários sobre estratégias de fallback em caso de falha no recebimento de webhooks mostrou-se insuficiente. Orientar os usuários a implementar mecanismos de consulta ativa como alternativa é uma melhoria importante para reduzir o impacto percebido em incidentes futuros.