Vorfallbericht: Datenbanklast, kaskadierende Ausfälle und was wir daraus gelernt haben – 27. Januar 2026

Auswirkungen

• Benutzer mit geringem Volumen erlebten hohe Latenz und langsame Seitenladezeiten

• Enterprise-Kunden mit stark frequentierten Eventtypen erlebten Timeouts und Ausfallzeiten

• Später im Vorfall sahen Benutzer mit Google-Kalender-Integrationen intermittierende Fehler

Was wir zuerst sahen

Um 15:30 UTC lösten automatische Warnmeldungen wegen erhöhter Datenbanklast aus. Erste Untersuchungen zeigten steigende Average Active Sessions (AAS) und rasch zunehmende Statement-Latenz, während der gesamte Traffic innerhalb der erwarteten Grenzen blieb.

Was diese Grafik zeigt:

• Ein anhaltender Anstieg aktiver Datenbanksitzungen

• Sitzungen stauten sich auf, statt schnell abgeschlossen zu werden

• Ein starkes Signal dafür, dass Abfragen langsamer wurden und nicht der Traffic zunahm

Dies deutete auf eine Änderung an unserer Anwendung hin und nicht auf einen Traffic-Spike, was die Traffic-Analyse bestätigte.

CPU-Auslastung bestätigt den Engpass

Mit steigender Last folgte die CPU-Auslastung der Datenbank.

Was diese Grafiken zeigen:

• CPU-Auslastung steigt deutlich über das Basisniveau

• Anhaltende Sättigung statt kurzer Spitzen

• Klare Korrelation mit steigender Abfrage-Latenz

Zu diesem Zeitpunkt war Postgres CPU-gebunden. Abfragen liefen länger, blockierten andere, und die Latenz breitete sich im System aus.

Zeitachse (UTC)

• 15:30 – Automatische Warnmeldungen wegen hoher DB-Last. Erste Diagnosen zeigten erhöhte DELETE-Aktivität auf APIv2.

• 15:49 – Wir verschärften die DELETE-Rate-Limits, um den unmittelbaren Druck zu verringern.

• 16:03 – Weitere Untersuchungen zeigten, dass der Traffic normal war. Die Datenbanklast stieg weiter an.

• 16:06 – Erste Berichte von enterprise-Kunden, die Eventtypen nicht laden konnten.

• 16:18 – Vorfall erklärt. CPU-Sättigung führte dazu, dass die Statement-Latenz im gesamten System anstieg.

• 17:07 – Wir begannen, eine stark belastete Abfrage umzuschreiben, um den Druck auf die Datenbank zu verringern.

• 17:40 – Das Umschreiben der Abfrage wurde bereitgestellt. Das half, löste das Problem aber nicht vollständig.

Der entscheidende Wendepunkt

Um 17:45 identifizierten wir eine unbeabsichtigte Wechselwirkung:
Eine kürzlich am Montag, dem 26., veröffentlichte Funktion führte die Buchungssuche in KBar (CMD+K) ein. Dadurch wurde bei jedem Seitenaufruf in der Web-App ein schwerer API-Aufruf ausgeführt.
Um 17:55 wurde die KBar-Änderung in der Produktion zurückgesetzt.

Was diese Grafik bestätigt:

• Ein deutlicher und sofortiger Rückgang der AAS nach dem Zurücksetzen

• Der Druck durch Datenbankabfragen nahm ab

• Die Latenz stabilisierte sich kurz darauf

Dies stimmt genau mit dem Zeitpunkt des Rücksetzens überein und bestätigte die KBar-Interaktion als primären Auslöser des Datenbankvorfalls.

• 18:15 – Die Datenbankleistung stabilisierte sich.
  Der primäre DB-Vorfall war an diesem Punkt behoben.

Aufgedeckte sekundäre Probleme

Nachdem sich die Datenbank erholt hatte, blieb ein kleinerer Teil der Nutzer betroffen.
Nutzer mit Google-Kalender-Integrationen erlebten Fehler aufgrund der Ausschöpfung des Google-API-Kontingents. Dies wurde durch das Wiederholungsverhalten mehrerer Consumer verursacht, während Upstream-Fehler auftraten.

Was diese Grafik zeigt:

• Schneller Verbrauch des Kontingents während des Vorfallsfensters

• Korrelation mit Wiederholungsverhalten statt mit neuem Traffic

• 18:40 – Grundursache identifiziert: Die Retry-Logik von Atoms aktualisierte Kalender aggressiv.

• 18:46 – Die Funktionalität von Atoms war vorübergehend unterbrochen. Kalenderereignisse wurden nachgetragen und die Kontingentnutzung sank.

• 18:54 – Die Leistung von APIv2 blieb leicht beeinträchtigt; ein Teil des Traffics wurde vorübergehend auf Vercel-Endpunkte umgeleitet.

• 19:30 – APIv2 und Google-Integrationen stabilisierten sich vollständig.

Später identifizierten wir ein weiteres beitragendes Problem:

• Ein nicht erwarteter, promisifizierter Aufruf führte dazu, dass Node-Prozesse abstürzten, wenn Google-API-Fehler in den globalen Scope gelangten.

Grundursache

Die Hauptursache war eine unerwartete Wechselwirkung zwischen Funktionen:

• KBar löste bei jedem Seitenaufruf einen schweren API-Aufruf aus

• Dieser API-Pfad stützte sich auf teure Datenbankabfragen, insbesondere für Nutzer im großen Maßstab mit vielen Buchungen.

• CPU-Sättigung erhöhte die Abfrage-Latenz im gesamten System

• Enterprise-Kunden mit stark frequentierten Eventtypen waren am stärksten betroffen

Sekundäre Ausfälle (Ausschöpfung des Google-Kontingents und Instabilität von APIv2) waren nicht die ursprüngliche Ursache, traten aber zutage, als das System unter Stress stand.

Was wir geändert haben

Seit Dienstag haben wir:

• Die KBar-Kopplung entfernt, die schwere API-Aufrufe auslöste (#27314)

• Mehrere Abfrageoptimierungen ausgeliefert, um die DB-Last zu reduzieren (#27364, #27319, #27309, #27315)

• Die Paginierung für /booking/{upcoming,…} von vorgerendert auf On-Demand umgestellt, wodurch die Datenbanknutzung reduziert wurde, während wir den Endpunkt weiter optimieren (#27351)

• Den nicht erwarteten asynchronen Aufruf behoben, der in APIv2 Node-Prozessabstürze verursachte(#27313)

• Auf DB-Ebene verschiedene Schutzmaßnahmen eingeführt, um unsere Datenbank in Zeiten extremer Nutzung zu schützen.

• Aufrufe an DELETE-Endpunkte auf 1 Anfrage pro Sekunde begrenzt (#27359)

Abschluss

Dieser Vorfall wurde nicht durch Traffic-Spitzen oder einen Infrastrukturausfall verursacht. Er wurde durch eine unerwartete Wechselwirkung von Funktionen verursacht, mit kaskadierenden Problemen aufgrund des Retry-Verhaltens downstream und einem subtilen Anwendungsfehler.

Wir entschuldigen uns für die Störung, insbesondere für Kunden im großen Maßstab. Der Vorfall vom Dienstag floss direkt in Verbesserungen dafür ein, wie wir Funktionen ausliefern, unsere Datenbank schützen und kaskadierende Ausfälle handhaben.

Danke für Ihre Geduld und dafür, dass Sie uns an hohen Maßstäben messen.