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

Impacto

• Usuários de baixo volume tiveram alta latência e carregamento lento das páginas

• Clientes enterprise com scheduling links de alto volume tiveram timeouts e indisponibilidade

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

O que vimos primeiro

Às 15:30 UTC, alertas automáticos foram acionados por causa de carga elevada no banco de dados. A investigação inicial mostrou aumento de Average Active Sessions (AAS) e crescimento rápido da latência das statements, enquanto o tráfego geral permaneceu dentro do esperado.

O que este gráfico mostra:

• Um aumento sustentado nas sessões ativas do banco de dados

• Sessões se acumulando em vez de serem concluídas rapidamente

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

Isso sugeriu uma mudança na nossa aplicação, e não um pico de tráfego, o que a análise de tráfego confirmou.

A saturação de CPU confirma o gargalo

À medida que a carga aumentava, o uso de CPU do banco de dados acompanhava.

O que esses gráficos mostram:

• Utilização de CPU subindo bem acima da linha de base

• Saturação sustentada, em vez de picos curtos

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

Nesse ponto, o Postgres estava limitado pela CPU. As queries estavam levando mais tempo, bloqueando outras, e a latência se espalhou pelo sistema.

Linha do tempo (UTC)

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

• 15:49 – A gente apertou os limites de taxa de DELETE para reduzir a pressão imediata.

• 16:03 – Investigação adicional mostrou que o tráfego estava normal. A carga do banco de dados continuou subindo.

• 16:06 – Primeiros relatos de clientes enterprise sem conseguir carregar scheduling links.

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

• 17:07 – A gente começou a reescrever uma query de alta carga para reduzir a pressão no banco de dados.

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

O ponto de virada principal

Às 17:45, identificamos uma interação não intencional:
Um recurso recente lançado na segunda-feira, dia 26, introduziu a busca de booking dentro do KBar (CMD+K). Isso fez com que uma chamada pesada de API fosse executada em cada carregamento de página no app web.
Às 17:55, a mudança do KBar foi revertida em produção.

O que este gráfico confirma:

• Uma queda clara e imediata no AAS depois da reversão

• Redução da pressão das queries no banco de dados

• A latência se estabilizando logo depois

Isso corresponde exatamente ao momento da reversão e confirmou a interação com o KBar como o principal gatilho do incidente no banco de dados.

• 18:15 – O desempenho do banco de dados estabilizou.
  O incidente principal no BD foi resolvido neste ponto.

Problemas secundários descobertos

Depois que o banco de dados se recuperou, um subconjunto menor de usuários continuou afetado.
Usuários com integrações do Google Calendar tiveram falhas devido ao esgotamento da cota da Google API. Isso foi causado pelo comportamento de retry em vários consumidores enquanto erros upstream estavam ocorrendo.

O que este gráfico mostra:

• Consumo rápido da cota 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 do Atoms atualizando calendars de forma agressiva.

• 18:46 – A funcionalidade do Atoms foi interrompida temporariamente. Os eventos do Calendar foram preenchidos retroativamente e o uso da cota caiu.

• 18:54 – O desempenho da APIv2 permaneceu levemente degradado; parte do tráfego foi temporariamente redirecionada para endpoints da Vercel.

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

Mais tarde, identificamos um problema adicional que contribuiu:

• Uma chamada async promisificada não aguardada fez processos Node travarem quando erros da Google API escaparam para o escopo global.

Causa raiz

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

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

• Esse caminho da API dependia de queries caras no banco de dados; principalmente para usuários em grande escala com muitas bookings.

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

• Clientes enterprise com scheduling links de alto volume foram os mais impactados

As falhas secundárias (esgotamento de cota do Google e instabilidade da APIv2) não foram a causa original, mas apareceram quando o sistema estava sob estresse.

O que mudamos

Desde terça-feira, a gente:

• Removeu a dependência do KBar que disparava chamadas pesadas de API (#27314)

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

• Mudou a paginação de /booking/{upcoming,…} de pré-renderizada para sob demanda, reduzindo o uso do banco de dados enquanto seguimos otimizando o endpoint (#27351)

• Corrigiu a chamada async não aguardada que causava travamentos do processo Node na APIv2(#27313)

• Colocou várias proteções no nível do BD para proteger nosso banco de dados durante períodos de uso extremo.

• Limitou as chamadas para endpoints de DELETE a 1 requisição por segundo (#27359)

Encerramento

Este incidente não foi causado por picos de tráfego ou falha de infraestrutura. Ele foi causado por uma interação inesperada entre recursos, com problemas em cascata devido ao comportamento de retry downstream e a um bug sutil na aplicação.

Pedimos desculpas pela interrupção, especialmente para clientes que operam em escala. O incidente de terça-feira influenciou diretamente melhorias em como lançamos recursos, protegemos nosso banco de dados e lidamos com falhas em cascata.

Obrigado pela sua paciência e por nos cobrar um padrão alto.