Instabilidade nos serviços de mensagerias da Unico, impactando todos os produtos integrados aos fluxos de mensagens

Update timeline

1. investigating Jan 21, 2026, 11:51 PM UTC

   Identificamos uma degradação as 20h07 em nossa plataforma de mensageria, gerando falhas no fluxo de mensagens dos produtos ID Check, ID Unico, integração By Unico, IDPay, Unico People, Unico Auto, ID SIGN.

2. monitoring Jan 21, 2026, 11:52 PM UTC

   Os serviços de SMS e mensageria foram reestabelecidos. Nossa equipe segue acompanhando e monitorando os indicadores deste recurso. Agradecemos a compreensão e em breve retornaremos com mais informações

3. resolved Jan 22, 2026, 12:08 AM UTC

   Relatório de Incidente: Instabilidade no Serviço de Mensageria Resumo Executivo e Impacto: No dia 21 de janeiro de 2026, identificamos uma instabilidade que afetou o processamento de novas solicitações em nossa plataforma. Durante o período do incidente, aproximadamente 6% das requisições ao endpoint de criação de processos apresentaram falhas ou tempos de resposta elevados (timeouts). O impacto foi limitado a uma fração das operações de mensageria, não afetando a integridade dos dados armazenados ou outros serviços core da infraestrutura. Causa Raiz e Resolução: A investigação técnica determinou que o incidente foi causado pela saturação de memória na camada de cache (Redis), o que levou o serviço de gerenciamento de mensagens a um estado de reinicialização contínua (crash loop). Para normalizar a operação, a equipe de engenharia expandiu a capacidade de escalonamento automático do serviço, dobrando o número mínimo de instâncias ativas para garantir a disponibilidade sob carga. Após o redimensionamento e a reinicialização dos componentes afetados, o serviço foi restabelecido integralmente e a taxa de erro retornou aos níveis nominais. Reforçamos nosso compromisso com a transparência e permanecemos à disposição para quaisquer esclarecimentos adicionais por meio dos nossos canais oficiais de suporte. Atenciosamente, Equipe Unico.

4. postmortem Feb 06, 2026, 01:53 PM UTC

   # Postmortem: **Data do Incidente:** 21 de janeiro de 2026 **Duração do Impacto:** Aproximadamente 1 hora e 10 minutos ### Resumo Executivo Em 21 de janeiro de 2026, entre 19:25 e 20:30 \(horário de Brasília\), nossa plataforma enfrentou uma instabilidade no sistema de mensageria. O incidente resultou em latência elevada e falhas no envio de notificações transacionais \(SMS, E-mail e WhatsApp\). A equipe de engenharia identificou a causa raiz relacionada à saturação de recursos de infraestrutura devido a um pico de tráfego atípico e aplicou as correções necessárias para restabelecer o serviço. ### Impacto Durante o período do incidente, o serviço responsável pelo gerenciamento de mensagens ficou indisponível, afetando as seguintes operações: * **Envio de Notificações:** Falhas e atrasos significativos na entrega de mensagens críticas via SMS, E-mail e WhatsApp para os usuários finais. * **Jornadas do Cliente:** Fluxos de negócios que dependem dessas comunicações \(como validações de token ou confirmações de cadastro\) sofreram interrupções ou lentidão. * **Latência:** Observou-se um aumento expressivo no tempo de resposta das APIs de mensageria antes da interrupção total do serviço. ### Causa Raiz A investigação técnica determinou que a causa raiz foi a **saturação de memória no cluster de cache \(Redis\)** utilizado pelo sistema de mensageria. O incidente foi desencadeado pela execução de um processamento em lote \(_batch_\) de grande volume, que gerou uma demanda massiva e inesperada de requisições. O volume de dados excedeu a capacidade de memória provisionada \(5GB\) do banco de dados em memória, ativando mecanismos de proteção \(OOM Prevention\) que bloquearam novas escritas. Como consequência, os servidores da aplicação perderam a conexão com o cache e entraram em estado de falha \(_CrashLoopBackOff_\), tornando o serviço indisponível. ### Resolução e Recuperação A equipe de resposta a incidentes atuou nas seguintes frentes para mitigar e resolver o problema: 1. **Diagnóstico:** Identificação da falha de conexão e confirmação da saturação de memória no Redis. 2. **Escalonamento Horizontal:** Aumento imediato do número mínimo de réplicas \(pods\) do serviço de mensageria para lidar com a demanda represada. 3. **Escalonamento Vertical:** Aumento da capacidade de memória do cluster Redis de 5GB para 10GB, dobrando a disponibilidade de recursos. 4. **Estabilização:** Após a conclusão do escalonamento, o fluxo de mensagens foi normalizado e a latência retornou aos níveis operacionais padrões. ### Lições Aprendidas Para prevenir a recorrência deste cenário e aumentar a resiliência da plataforma, mapeamos os seguintes aprendizados: * **Melhoria na Observabilidade:** Implementação de alertas preventivos específicos para monitorar a saturação de recursos \(memória\) e a saúde dos componentes de cache, permitindo uma reação antes da indisponibilidade. * **Auto-scaling de Infraestrutura:** Revisão das políticas de infraestrutura para permitir o escalonamento automático de memória nos serviços de dados, adequando-se dinamicamente a picos de tráfego. * **Resiliência da Aplicação:** Adoção de padrões de _Graceful Degradation_ \(degradação graciosa\), garantindo que o sistema possa operar de forma limitada ou gerenciar falhas de dependências sem colapsar completamente