Revisione dell'incidente: carico del database, fallimenti a cascata e ciò che abbiamo imparato - 27 gennaio 2026

Impatto

• Gli utenti a basso volume hanno sperimentato alta latenza e caricamenti lenti delle pagine

• I clienti enterprise con tipi di eventi pesanti hanno subito timeout e inattività

• Più tardi nell'incidente, gli utenti con integrazioni di Google Calendar hanno visto guasti intermittenti

Cosa abbiamo visto per primo

Alle 15:30 UTC, gli avvisi automatici sono stati attivati per un carico elevato del database. L'indagine iniziale ha mostrato un aumento delle Sessioni Attive Medie (AAS) e una rapida crescita della latenza delle dichiarazioni, mentre il traffico complessivo è rimasto nei limiti previsti.

Cosa mostra questo grafico:

• Un aumento costante delle sessioni attive del database

• Le sessioni si accumulano piuttosto che completarsi rapidamente

• Un forte segnale che le query stavano diventando più lente, non che il traffico fosse aumentato

Questo suggeriva un cambiamento nella nostra applicazione piuttosto che un picco di traffico, come confermato dall'analisi del traffico.

La saturazione della CPU conferma il collo di bottiglia

Con l'aumento del carico, l'utilizzo della CPU del database è aumentato.

Cosa mostrano questi grafici:

• L'utilizzo della CPU è salito ben al di sopra della linea di base

• Saturazione sostenuta piuttosto che picchi brevi

• Chiara correlazione con l'aumento della latenza delle query

A questo punto, Postgres era limitato dalla CPU. Le query duravano di più, bloccando altre e la latenza si diffondeva attraverso il sistema.

Cronologia (UTC)

• 15:30 – Avvisi automatici per il carico elevato del DB. I diacritici iniziali hanno mostrato un'attività elevata di DELETE su APIv2.

• 15:49 – Abbiamo stretto i limiti di velocità DELETE per ridurre la pressione immediata.

• 16:03 – Ulteriori indagini hanno mostrato che il traffico era normale. Il carico del database continuava a crescere.

• 16:06 – Prime segnalazioni di clienti enterprise impossibilitati a caricare tipi di eventi.

• 16:18 – Incidente dichiarato. La saturazione della CPU ha causato un aumento della latenza delle dichiarazioni nel sistema.

• 17:07 – Abbiamo iniziato a riscrivere una query a carico elevato per ridurre la pressione sul database.

• 17:40 – Riscrittura della query implementata. Questo ha aiutato, ma non ha completamente risolto il problema.

Il punto di svolta chiave

Alle 17:45, abbiamo identificato un'interazione non voluta:
Una recente funzionalità rilasciata lunedì 26 ha introdotto la ricerca di prenotazioni all'interno di KBar (CMD+K). Questo ha causato una pesante chiamata API da eseguire a ogni caricamento della pagina nell'app web.
Alle 17:55, la modifica di KBar è stata annullata in produzione.

Cosa conferma questo grafico:

• Una chiara e immediata diminuzione delle AAS dopo l'annullamento

• La pressione delle query del database ridotta

• La latenza si stabilizza poco dopo

Questo si allinea esattamente con il timing dell'annullamento e ha confermato l'interazione di KBar come il principale fattore scatenante dell'incidente del database.

• 18:15 – Le prestazioni del database si sono stabilizzate.
  L'incidente principale del DB è stato risolto a questo punto.

Problemi secondari scoperti

Dopo il recupero del database, un sottoinsieme più piccolo di utenti è rimasto colpito.
Gli utenti con integrazioni di Google Calendar hanno subito guasti a causa dell'esaurimento del quota API di Google. Questo è stato causato dal comportamento di ripetizione attraverso più consumatori mentre si verificavano errori a monte.

Cosa mostra questo grafico:

• Consumo rapido della quota durante la finestra dell'incidente

• Correlazione con il comportamento di ripetizione piuttosto che con nuovo traffico

• 18:40 – Causa principale identificata: la logica di ripetizione degli Atomi aggiorna aggressivamente i calendari.

• 18:46 – La funzionalità degli Atomi è stata temporaneamente interrotta. Gli eventi del calendario sono stati ripristinati e l'uso della quota è diminuito.

• 18:54 – Le prestazioni di APIv2 sono rimaste leggermente degradate; parte del traffico è stata temporaneamente reindirizzata agli endpoint Vercel.

• 19:30 – APIv2 e integrazioni Google si sono stabilizzate completamente.

In seguito, abbiamo identificato un ulteriore problema contribuente:

• Una chiamata promisificata non attesa ha causato il crash dei processi Node quando gli errori API di Google sono sfuggiti allo scope globale.

Causa principale

La causa principale è stata un'interazione inaspettata tra funzionalità:

• KBar ha attivato una pesante chiamata API a ogni caricamento della pagina

• Questo percorso API si basava su query di database costose; particolarmente per gli utenti di larga scala con molte prenotazioni.

• La saturazione della CPU ha aumentato la latenza delle query nel sistema

• I clienti enterprise con tipi di eventi ad alto volume sono stati i più colpiti

Le anomalie secondarie (esaurimento delle quote di Google e instabilità di APIv2) non erano la causa originale, ma sono state rivelate una volta che il sistema era sotto stress.

Cosa abbiamo cambiato

Da martedì, abbiamo:

• Rimosso il collegamento KBar che attivava pesanti chiamate API (#27314)

• Implementato diverse ottimizzazioni delle query per ridurre il carico sul DB (#27364, #27319, #27309, #27315)

• Cambiato la paginazione per /booking/{upcoming,…} da pre-rendered a on-demand, riducendo l'uso del database mentre continuiamo a ottimizzare l'endpoint (#27351)

• Corretto la chiamata async non attesa che causava i crash dei processi Node in APIv2(#27313)

• Implementato vari meccanismi di protezione a livello di DB per proteggere il nostro database durante i periodi di utilizzo estremo.

• Limitato le chiamate agli endpoint DELETE a 1 richiesta al secondo (#27359)

Chiusura

Questo incidente non è stato causato da picchi di traffico o guasti infrastrutturali. È stato causato da un'interazione inaspettata tra funzionalità, con problemi a cascata a causa del comportamento di ripetizione a valle e di un bug sottile nell'applicazione.

Ci scusiamo per la perturbazione, soprattutto per i clienti che operano su larga scala. L'incidente di martedì ha direttamente informato le migliorie a come spediamo le funzionalità, proteggiamo il nostro database e gestiamo i fallimenti a cascata.

Grazie per la vostra pazienza e per mantenere un elevato standard.