Instabilidade nos serviços de notificações via Webhook ID Cloud

Update timeline

1. resolved Mar 19, 2026, 01:13 PM UTC

   Instabilidade nos serviços de notificações via Webhook ID Cloud Resumo Executivo e Impacto: Informamos que tivemos um incidente relacionado à latência no processamento de notificações via webhook. O impacto principal ocorreu em uma janela curta de tempo, entre 08:35 e 08:45 (BRT), período em que identificamos um atraso na entrega de status de transações. Reforçamos que não houve perda de dados, comprometimento da integridade das informações ou interrupção no nosso motor de liveness. Todas as transações processadas durante esse intervalo tiveram suas notificações devidamente entregues após a estabilização do serviço. Causa Raiz e Resolução: A causa raiz foi uma instabilidade em nossa infraestrutura. Nossas métricas internas confirmaram uma anomalia crítica entre 08:34 e 08:48, com o pico de latência concentrado na janela de 10 minutos mencionada anteriormente. Esta falha na camada de transporte de dados impediu que os webhooks fossem disparados em tempo real. Embora o processamento central estivesse operacional, o atraso na recepção desses status pode ter gerado a percepção de indisponibilidade sistêmica. Atuamos imediatamente na mitigação do gargalo e na vazão das filas represadas para normalizar o fluxo de comunicação. Compromisso e Próximos Passos: Nossa prioridade agora é o fortalecimento da resiliência técnica e a melhoria contínua da experiência de integração: - Monitoramento: Estamos aprimorando nossas métricas de observabilidade para detectar anomalias em serviços de terceiros com maior granularidade e velocidade. - Postmortem: Um relatório técnico detalhado (Postmortem) será compartilhado em breve, aprofundando as ações estruturais que tomaremos para evitar recorrências. Recomendação de implementação para clientes: uso GetProcess como fallback: Conforme detalhado em nossa documentação técnica [https://devcenter.unico.io/unico-idcloud/by-unico-integration/adittional-resources/webhooks], reforçamos a recomendação do uso de método de contingência (GetProcess) para cenários onde a implementação do cliente identifica instabilidade/degradação do envio do webhook. Isso garante que a operação continue recebendo status sem interrupções. Pedimos desculpas por qualquer impacto causado e agradecemos a compreensão. Equipe Unico.

2. postmortem Mar 30, 2026, 07:16 PM UTC

   ## Postmortem: Instabilidade nos serviços de notificações via Webhook ID Cloud ### Resumo Em 19 de março de 2026, o serviço responsável pela publicação de eventos de Change Data Capture \(CDC\) — essencial para a entrega de notificações via webhook — apresentou falhas intermitentes. O serviço entrou em um ciclo de reinicialização automática após falhas de comunicação com o provedor de nuvem, resultando em atrasos no processamento de notificações para diversos clientes. ‌ ### Impacto O incidente durou aproximadamente **10 minutos**, entre 08:33 e 08:43 BRT. Durante este intervalo, as atualizações de status que deveriam ser entregues em tempo real sofreram atrasos. ‌ * Cerca de **12.177 notificações** de webhook foram retidas temporariamente na fila de processamento. * Dois clientes de grande porte concentraram a maior parte do volume afetado, com aproximadamente **8.340** e **3.393** atualizações atrasadas, respectivamente. * Não houve perda de dados ou comprometimento da integridade das informações; todas as mensagens foram entregues com sucesso após a estabilização do serviço. ### Causa Raiz O incidente foi desencadeado por uma combinação de fatores técnicos e de infraestrutura: * **Instabilidade no Provedor de Nuvem:** Ocorreu um pico transitório de latência no serviço de mensageria do Google Cloud, resultando em erros de conexão e tempos de resposta extremamente elevados. * **Limitação de Design do Conector:** O componente utilizado para processar as mensagens estava configurado para tratar qualquer tempo de espera \(timeout\) superior a 30 segundos como um erro fatal e não recuperável. * **Volume de Processamento:** Devido a um grande lote de mensagens sendo processado simultaneamente, o atraso em apenas 11 delas foi suficiente para exceder o limite de tempo e derrubar o serviço por completo. * **Configurações de Legado:** O serviço ainda operava com parâmetros de configuração antigos, que não incluíam políticas de retentativa ou tolerância a falhas de rede temporárias. ### Resolução Após a identificação do gargalo na infraestrutura de nuvem e das falhas no serviço de saída, a equipe técnica realizou a reinicialização dos componentes afetados. Uma vez restabelecida a conectividade com o provedor de nuvem, o sistema processou automaticamente o acúmulo de mensagens em cerca de 5 minutos, normalizando a entrega de todas as notificações pendentes. ‌ ### Lições Aprendidas * **Desacoplamento de Melhorias e Migrações:** Identificamos que melhorias críticas de resiliência não devem ficar estritamente atreladas a grandes migrações de infraestrutura, sob o risco de manter serviços expostos a falhas conhecidas por mais tempo do que o necessário. * **Redução do Raio de Exposição:** O uso de lotes de processamento muito grandes pode aumentar o impacto de falhas isoladas. Ajustar o tamanho desses lotes ajuda a isolar problemas de rede. * **Monitoramento Proativo de Latência:** A ausência de alertas específicos para latência de publicação impediu uma detecção precoce antes que o limite de interrupção do serviço fosse atingido. * **Resiliência como Padrão:** Configurações de retentativa e tratamento de erros devem ser padronizadas em todos os conectores de dados para suportar a volatilidade natural de ambientes de nuvem. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.‌ Atenciosamente, Equipe Unico.