Instabilidade no Serviço de entrega de WebHook (IDCloud)

Update timeline

1. resolved Feb 17, 2026, 07:48 PM UTC

   Resumo Executivo: No dia 17 de fevereiro de 2026, nosso sistema enfrentou uma instabilidade temporária causada por um volume atípico de requisições em um curto período, entre 14:48 e 15:09. Este pico de tráfego sobrecarregou o sistema de mensageria, resultando em timeouts que interromperam o processamento de captura de dados. Como consequência, alguns clientes observaram um aumento em erros de limite de taxa (HTTP 429) e latência elevada em determinados endpoints durante o período de maior demanda. A resolução foi alcançada através da reinicialização dos serviços afetados e do escalonamento de recursos para absorver a carga excedente. Após as medidas de mitigação, o ambiente foi monitorado continuamente e apresenta estabilidade plena há mais de 30 minutos, sem novas ocorrências. Estamos revisando nossos mecanismos de resiliência e tolerância a falhas no processamento de eventos para garantir que o sistema lide de forma mais autônoma com flutuações severas de tráfego no futuro. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

2. postmortem Mar 09, 2026, 05:32 PM UTC

   ## Relatório de Incidente: Instabilidade no Serviço de entrega de WebHook \(IDCloud\) ### Resumo Em 17 de fevereiro de 2026, nosso serviço de notificação de eventos \(Webhooks\) apresentou instabilidade e queda na taxa de sucesso, operando abaixo da meta estabelecida de **97,6%**. O incidente foi desencadeado por uma falha técnica no componente de captura de dados, que parou de processar eventos devido a uma instabilidade externa. Após o restabelecimento manual do serviço, o volume acumulado de mensagens causou uma sobrecarga temporária em nossa infraestrutura de entrega. ### Impacto * **Duração do Impacto Total:** Aproximadamente 1 hora e 7 minutos. * **Serviços Afetados:** Fluxo de criação de eventos via Webhook. * **Experiência do Cliente:** Alguns clientes enfrentaram atrasos no recebimento de notificações de finalização de jornada. Devido a esse atraso, houve um aumento nas tentativas manuais de reprocessamento e consultas de status \(GET\), o que resultou em erros temporários de limite de taxa \(_rate limiting_ - HTTP 429\). ### Causa Raiz O incidente foi originado por uma combinação de fatores técnicos e de infraestrutura: 1. **Instabilidade Externa:** Uma oscilação transiente na infraestrutura de mensageria em nuvem \(Pub/Sub\) causou falhas de conexão no worker de processamento. 2. **Falha na Recuperação Automática:** Devido à ausência de configurações específicas de tempo limite de encerramento \(_shutdown timeout_\) e de verificações de integridade, o serviço entrou em um estado de "travamento" silencioso. Ele parou de consumir dados, mas não reiniciou automaticamente para recuperar a conexão. 3. **Efeito Cascata:** Durante os 18 minutos em que o serviço ficou inativo, uma grande quantidade de eventos acumulou-se na fila. Ao ser reiniciado manualmente, o sistema tentou processar todo o backlog de uma só vez, gerando um pico de tráfego que saturou as conexões do banco de dados do serviço de webhook. ### Resolução A mitigação foi realizada por nossa equipe de engenharia de confiabilidade \(SRE\) através do **reinício manual dos serviços travados**. Após o restart, o sistema passou por um período de instabilidade enquanto drenava o backlog acumulado, estabilizando-se completamente às 15h55 BRT. O monitoramento subsequente confirmou que a taxa de sucesso retornou aos níveis normais de SLO e o volume de requisições dos clientes foi normalizado. ### Lições Aprendidas * **Resiliência a Falhas Externas:** Identificamos que o componente de captura de dados precisa de configurações de _timeout_ mais agressivas para garantir que o processo finalize e reinicie em caso de latência de rede externa. * **Necessidade de Throttling:** A ausência de um mecanismo de controle de vazão \(_throttling_\) na drenagem de backlogs torna o sistema vulnerável a surtos de tráfego após períodos de inatividade. * **Automação do MTTR:** Depender de intervenção manual e escalonamento de permissões aumenta o tempo médio de recuperação \(MTTR\). A implementação de verificações de saúde automatizadas é essencial para a autorrecuperação.