Revue de l'incident : charge de la base de données, défaillances en cascade et ce que nous avons appris - 27 janvier 2026

Impact

• Les utilisateurs à faible volume ont rencontré une latence élevée et des temps de chargement de page lents

• Les clients d'entreprise avec des types d'événements lourds ont connu des délais d'attente et des temps d'arrêt

• Plus tard dans l'incident, les utilisateurs ayant des intégrations avec Google Calendar ont constaté des défaillances intermittentes

Ce que nous avons vu en premier

À 15h30 UTC, des alertes automatiques ont été déclenchées en raison d'une charge de base de données élevée. Une première enquête a montré une augmentation des sessions actives moyennes (AAS) et une latence des déclarations en forte hausse, tandis que le trafic global restait dans des limites attendues.

Ce que ce graphique montre :

• Une augmentation soutenue des sessions actives de la base de données

• Des sessions s'accumulant plutôt que de se terminer rapidement

• Un signal fort que les requêtes devenaient plus lentes, et non que le trafic avait augmenté

Cela a suggéré un changement dans notre application plutôt qu'une augmentation de trafic, ce que l'analyse de trafic a confirmé.

La saturation du CPU confirme le goulet d'étranglement

À mesure que la charge augmentait, l'utilisation du CPU de la base de données augmentait également.

Ce que ces graphiques montrent :

• L'utilisation du CPU dépassant largement la référence

• Saturation soutenue plutôt que pics courts

• Corrélation claire avec la latence des requêtes en augmentation

À ce stade, Postgres était limité par le CPU. Les requêtes prenaient plus de temps, bloquaient d'autres, et la latence se répandait dans le système.

Chronologie (UTC)

• 15h30 – Alertes automatiques pour charge élevée de la base de données. Les diagnostics initiaux ont montré une activité DELETE élevée sur APIv2.

• 15h49 – Nous avons renforcé les limites de taux de DELETE pour réduire la pression immédiate.

• 16h03 – Une enquête plus approfondie a montré que le trafic était normal. La charge sur la base de données continuait d'augmenter.

• 16h06 – Premiers rapports de clients d'entreprise incapables de charger des types d'événements.

• 16h18 – Incident déclaré. La saturation du CPU a causé une augmentation de la latence des déclarations dans tout le système.

• 17h07 – Nous avons commencé à réécrire une requête à charge élevée pour réduire la pression sur la base de données.

• 17h40 – Réécriture de requête déployée. Cela a aidé, mais n'a pas entièrement résolu le problème.

Le moment décisif

À 17h45, nous avons identifié une interaction imprévue :
Une fonctionnalité récemment publiée le lundi 26 a introduit la recherche de réservation dans KBar (CMD+K). Cela a entraîné un appel API lourd sur chaque chargement de page dans l'application web.
À 17h55, le changement de KBar a été annulé en production.

Ce que ce graphique confirme :

• Une chute claire et immédiate des AAS après l'annulation

• Pression de requête sur la base de données réduite

• Latence se stabilisant peu après

Cela coïncide précisément avec le timing de l'annulation et a confirmé que l'interaction avec KBar était le principal déclencheur de l'incident de base de données.

• 18h15 – Performance de la base de données stabilisée.
  L'incident principal de la base de données a été résolu à ce moment-là.

Problèmes secondaires dévoilés

Après la récupération de la base de données, un sous-ensemble plus petit d'utilisateurs est resté affecté.
Les utilisateurs avec des intégrations Google Calendar ont rencontré des défaillances à cause de l'épuisement du quota de l'API Google. Cela a été causé par un comportement de réessaie à travers plusieurs consommateurs pendant que des erreurs en amont se produisaient.

Ce que ce graphique montre :

• Consommation rapide du quota pendant la fenêtre de l'incident

• Corrélation avec le comportement de réessaie plutôt qu'un nouveau trafic

• 18h40 – Cause fondamentale identifiée : La logique de réessaie d'Atoms rafraîchissant les calendriers de manière agressive.

• 18h46 – La fonctionnalité d'Atoms a été temporairement interrompue. Les événements de calendrier ont été remplis et l'utilisation du quota a diminué.

• 18h54 – La performance de l'APIv2 est restée légèrement dégradée ; un certain trafic a été temporairement redirigé vers les points de terminaison Vercel.

• 19h30 – APIv2 et intégrations Google pleinement stabilisées.

Plus tard, nous avons identifié un autre problème contribuant :

• Un appel promisifié non attendu a causé des plantages des processus Node lorsque les erreurs de l'API Google ont échappé au portée globale.

Cause fondamentale

La principale cause était une interaction inattendue entre les fonctionnalités :

• KBar a déclenché un appel API lourd à chaque chargement de page

• Ce chemin API s'appuyait sur des requêtes de base de données coûteuses ; particulièrement pour des utilisateurs à grande échelle avec de nombreuses réservations.

• La saturation du CPU a augmenté la latence des requêtes dans tout le système

• Les clients d'entreprise avec des types d'événements à fort volume ont été les plus touchés

Les défaillances secondaires (épuisement du quota Google et instabilité de l'APIv2) n'étaient pas la cause originale, mais ont été révélées une fois le système en stress.

Ce que nous avons changé

Depuis mardi, nous avons :

• Supprimé le couplage KBar qui déclenchait des appels API lourds (#27314)

• Livré plusieurs optimisations de requêtes pour réduire la charge sur la base de données (#27364, #27319, #27309, #27315)

• Changé la pagination pour /booking/{upcoming,…} de pré-rendu à la demande, réduisant l'utilisation de la base de données tout en continuant à optimiser le point de terminaison (#27351)

• Corrigé l'appel asynchrone non attendu causant des plantages de processus Node dans l'APIv2(#27313)

• Mis en place diverses précautions au niveau de la base de données pour protéger notre base de données pendant les périodes d'utilisation extrême.

• Limité les appels aux points de terminaison DELETE à 1 requête par seconde (#27359)

Conclusion

Cet incident n'a pas été causé par des pics de trafic ou une défaillance de l'infrastructure. Il a été causé par une interaction inattendue des fonctionnalités, avec des problèmes en cascade dus à un comportement de réessaie en aval et un bug subtil dans l'application.

Nous sommes désolés pour la perturbation, en particulier pour les clients opérant à grande échelle. L'incident de mardi a directement informé les améliorations apportées à la façon dont nous déployons des fonctionnalités, protégeons notre base de données et gérons les défaillances en cascade.

Merci pour votre patience et pour nous maintenir à un haut niveau d'exigence.