Revisão do incidente: carga da base de dados, falhas em cascata e o que aprendemos - 27 de janeiro de 2026

Impacto

• Utilizadores com baixo volume sofreram alta latência e carregamentos de página lentos

• Clientes enterprise com links de agendamento muito usados sofreram timeouts e interrupções

• Mais tarde no incidente, utilizadores com integrações do Google Calendar viram falhas intermitentes

O que vimos primeiro

Às 15:30 UTC, os alertas automáticos dispararam devido a uma carga elevada na base de dados. A investigação inicial mostrou um aumento das Average Active Sessions (AAS) e uma latência de statements a subir rapidamente, enquanto o tráfego geral se mantinha dentro dos limites esperados.

O que este gráfico mostra:

• Um aumento sustentado das sessões ativas na base de dados

• Sessões a acumular-se em vez de concluírem rapidamente

• Um sinal forte de que as queries estavam a ficar mais lentas, e não de que o tráfego tinha aumentado

Isto sugeria uma alteração na nossa aplicação em vez de um pico de tráfego, o que a análise de tráfego confirmou.

A saturação da CPU confirma o estrangulamento

À medida que a carga aumentava, o uso da CPU da base de dados seguia o mesmo caminho.

O que estes gráficos mostram:

• Utilização da CPU a subir muito acima da linha de base

• Saturação sustentada em vez de picos curtos

• Correlação clara com o aumento da latência das queries

A este ponto, o Postgres estava limitado pela CPU. As queries estavam a demorar mais, a bloquear outras e a latência espalhou-se pelo sistema.

Cronologia (UTC)

• 15:30 – Alertas automáticos para carga elevada na BD. Os diagnósticos iniciais mostraram atividade DELETE elevada em APIv2.

• 15:49 – Apertámos os limites de taxa de DELETE para reduzir a pressão imediata.

• 16:03 – A investigação adicional mostrou que o tráfego era normal. A carga da base de dados continuou a subir.

• 16:06 – Primeiros relatos de clientes enterprise incapazes de carregar links de agendamento.

• 16:18 – Incidente declarado. A saturação da CPU fez a latência dos statements aumentar em todo o sistema.

• 17:07 – Começámos a reescrever uma query de alta carga para reduzir a pressão sobre a base de dados.

• 17:40 – Reescrita da query implementada. Isto ajudou, mas não resolveu totalmente o problema.

O ponto de viragem principal

Às 17:45, identificámos uma interação inesperada:
Uma funcionalidade recente lançada na segunda-feira, dia 26, introduziu a pesquisa de bookings dentro do KBar (CMD+K). Isto fez com que uma chamada pesada à API fosse executada em cada carregamento de página na app web.
Às 17:55, a alteração no KBar foi revertida em produção.

O que este gráfico confirma:

• Uma queda clara e imediata na AAS após a reversão

• Redução da pressão das queries da base de dados

• A latência a estabilizar pouco depois

Isto alinha-se exatamente com o momento da reversão e confirmou a interação do KBar como o principal gatilho do incidente na base de dados.

• 18:15 – O desempenho da base de dados estabilizou.
  O incidente principal da BD foi resolvido neste ponto.

Problemas secundários descobertos

Depois de a base de dados recuperar, um subconjunto menor de utilizadores continuou afetado.
Utilizadores com integrações do Google Calendar sofreram falhas devido ao esgotamento da quota da API da Google. Isto foi causado pelo comportamento de retry em vários consumers enquanto ocorria erros a montante.

O que este gráfico mostra:

• Consumo rápido da quota durante a janela do incidente

• Correlação com comportamento de retry e não com novo tráfego

• 18:40 – Causa raiz identificada: lógica de retry dos Atoms a atualizar agressivamente os calendários.

• 18:46 – A funcionalidade dos Atoms foi temporariamente interrompida. Os eventos do calendário foram preenchidos retroativamente e o uso da quota desceu.

• 18:54 – O desempenho de APIv2 manteve-se ligeiramente degradado; algum tráfego foi temporariamente reencaminhado para endpoints da Vercel.

• 19:30 – APIv2 e as integrações da Google estabilizaram totalmente.

Mais tarde, identificámos um problema adicional contribuinte:

• Uma chamada promisified não aguardada fez com que processos Node crashassem quando erros da API da Google escapavam para o escopo global.

Causa raiz

A causa principal foi uma interação inesperada entre funcionalidades:

• O KBar desencadeou uma chamada pesada à API em cada carregamento de página

• Esse caminho da API dependia de queries de base de dados dispendiosas; sobretudo para utilizadores em grande escala com muitos bookings.

• A saturação da CPU aumentou a latência das queries em todo o sistema

• Os clientes enterprise com links de agendamento de grande volume foram os mais afetados

As falhas secundárias (esgotamento da quota da Google e instabilidade de APIv2) não foram a causa original, mas ficaram expostas quando o sistema ficou sob stress.

O que mudámos

Desde terça-feira, nós:

• Removemos a dependência do KBar que desencadeava chamadas pesadas à API (#27314)

• Lançámos várias otimizações de queries para reduzir a carga na BD (#27364, #27319, #27309, #27315)

• Alterámos a paginação de /booking/{upcoming,…} de pré-renderizada para a pedido, reduzindo o uso da base de dados enquanto continuamos a otimizar o endpoint (#27351)

• Corrigimos a chamada async não aguardada que causava crashes do processo Node em APIv2(#27313)

• Implementámos vários mecanismos de proteção ao nível da BD para proteger a nossa base de dados durante períodos de uso extremo.

• Limitámos as chamadas aos endpoints DELETE a 1 pedido por segundo (#27359)

Encerramento

Este incidente não foi causado por picos de tráfego nem por falha da infraestrutura. Foi causado por uma interação inesperada entre funcionalidades, com problemas em cascata devido ao comportamento de retry a jusante e a um bug subtil na aplicação.

Pedimos desculpa pela interrupção, especialmente aos clientes a operar em escala. O incidente de terça-feira informou diretamente melhorias na forma como lançamos funcionalidades, protegemos a nossa base de dados e lidamos com falhas em cascata.

Obrigado pela tua paciência e por nos exigires um padrão elevado.