Revue d’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 subi une forte latence et des chargements de page lents

• Les clients Enterprise avec des scheduling links très sollicités ont subi des délais d’attente et des interruptions

• Plus tard dans l’incident, les utilisateurs ayant des intégrations Google Calendar ont constaté des échecs intermittents

Ce que nous avons vu en premier

À 15:30 UTC, des alertes automatiques se sont déclenchées en raison d’une charge accrue de la base de données. L’enquête initiale a montré une augmentation des Average Active Sessions (AAS) et une hausse rapide de la latence des requêtes, tandis que le trafic global restait dans les limites attendues.

Ce que montre ce graphique :

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

• Des sessions qui s’accumulent au lieu de se terminer rapidement

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

Cela suggérait un changement dans notre application plutôt qu’un pic de trafic, ce que l’analyse du trafic a confirmé.

La saturation du CPU confirme le goulot d’étranglement

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

Ce que montrent ces graphiques :

• Une utilisation du CPU qui grimpe bien au-dessus du niveau de référence

• Une saturation soutenue plutôt que de brefs pics

• Une corrélation claire avec l’augmentation de la latence des requêtes

À ce stade, Postgres était limité par le CPU. Les requêtes s’exécutaient plus longtemps, bloquaient les autres et la latence s’est propagée dans tout le système.

Chronologie (UTC)

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

• 15:49 – Nous avons resserré les limites de débit de DELETE afin de réduire la pression immédiate.

• 16:03 – De nouvelles investigations ont montré que le trafic était normal. La charge de la base de données a continué d’augmenter.

• 16:06 – Premiers signalements de clients Enterprise incapables de charger les scheduling links.

• 16:18 – Incident déclaré. La saturation du CPU a entraîné une augmentation de la latence des requêtes dans tout le système.

• 17:07 – Nous avons commencé à réécrire une requête très sollicitée afin de réduire la pression sur la base de données.

• 17:40 – Déploiement de la réécriture de la requête. Cela a aidé, mais n’a pas entièrement résolu le problème.

Le tournant décisif

À 17:45, nous avons identifié une interaction involontaire :
Une fonctionnalité récente, publiée lundi 26, a introduit la recherche de réservation dans KBar (CMD+K). Cela a provoqué l’exécution d’un appel API lourd à chaque chargement de page dans l’application web.
À 17:55, le changement KBar a été annulé en production.

Ce que confirme ce graphique :

• Une baisse nette et immédiate de l’AAS après l’annulation

• Une pression sur les requêtes de la base de données réduite

• Une stabilisation de la latence peu après

Cela correspond exactement au moment de l’annulation et a confirmé l’interaction avec KBar comme déclencheur principal de l’incident de base de données.

• 18:15 – Les performances de la base de données se sont stabilisées.
  L’incident principal de la base de données a été résolu à ce moment-là.

Problèmes secondaires découverts

Après la récupération de la base de données, un sous-ensemble plus réduit d’utilisateurs est resté affecté.
Les utilisateurs ayant des intégrations Google Calendar ont subi des échecs en raison de l’épuisement du quota de l’API Google. Cela a été causé par un comportement de retry sur plusieurs consommateurs pendant que des erreurs en amont se produisaient.

Ce que montre ce graphique :

• Une consommation rapide du quota pendant la fenêtre de l’incident

• Une corrélation avec le comportement de retry plutôt qu’avec un nouveau trafic

• 18:40 – Cause racine identifiée : logique de retry d’Atoms qui rafraîchissait agressivement les calendriers.

• 18:46 – La fonctionnalité Atoms a été temporairement interrompue. Les événements du calendrier ont été remontés et l’utilisation du quota a baissé.

• 18:54 – Les performances d’APIv2 sont restées légèrement dégradées ; une partie du trafic a été temporairement redirigée vers des endpoints Vercel.

• 19:30 – APIv2 et les intégrations Google se sont stabilisées complètement.

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

• Un appel promisifié non attendu a provoqué le plantage des processus Node lorsque des erreurs de l’API Google ont échappé au scope global.

Cause racine

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

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

• Ce chemin API reposait sur des requêtes de base de données coûteuses ; en particulier pour les utilisateurs à grande échelle avec de nombreuses réservations.

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

• Les clients Enterprise ayant des scheduling links à fort volume ont été les plus touchés

Les défaillances secondaires (épuisement du quota Google et instabilité d’APIv2) n’étaient pas la cause initiale, mais sont apparues une fois le système sous 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 DB (#27364, #27319, #27309, #27315)

• Modifié la pagination de /booking/{upcoming,…} de pré-rendue à la demande, réduisant l’utilisation de la base de données pendant que nous continuons à optimiser l’endpoint (#27351)

• Corrigé l’appel async non attendu à l’origine de plantages du processus Node dans APIv2(#27313)

• Mis en place plusieurs garde-fous au niveau de la base de données pour protéger notre base pendant les périodes d’utilisation extrême.

• Limité le débit des appels vers les endpoints DELETE à 1 requête par seconde (#27359)

Conclusion

Cet incident n’a pas été causé par des pics de trafic ni par une défaillance de l’infrastructure. Il a été causé par une interaction inattendue entre fonctionnalités, avec des problèmes en cascade dus au comportement de retry en aval et à un bug subtil de 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 guidé des améliorations dans notre manière de livrer des fonctionnalités, de protéger notre base de données et de gérer les défaillances en cascade.

Merci pour votre patience et de nous maintenir à un niveau d’exigence élevé.