Incidentanalyse: databasebelasting, kettingreacties van storingen en wat we hebben geleerd - 27 januari 2026

Impact

• Gebruikers met laag volume ondervonden hoge latentie en trage paginaladingen

• Enterprise-klanten met zware eventtypes ondervonden time-outs en uitval

• Later in het incident zagen gebruikers met Google Calendar-integraties af en toe storingen

Wat we als eerste zagen

Om 15:30 UTC gingen automatische waarschuwingen af wegens verhoogde databasebelasting. Eerste onderzoek liet een stijgend aantal Average Active Sessions (AAS) en snel oplopende statementlatentie zien, terwijl het totale verkeer binnen de verwachte grenzen bleef.

Wat deze grafiek laat zien:

• Een aanhoudende toename van actieve databasesessies

• Sessies stapelden zich op in plaats van snel te voltooien

• Een sterk signaal dat queries trager werden, niet dat het verkeer was toegenomen

Dit suggereerde een wijziging in onze applicatie in plaats van een verkeerspiek, wat door verkeersanalyse werd bevestigd.

CPU-verzadiging bevestigt de bottleneck

Naarmate de belasting toenam, volgde het CPU-gebruik van de database.

Wat deze grafieken laten zien:

• CPU-gebruik dat ruim boven de basislijn uitsteeg

• Aanhoudende verzadiging in plaats van korte pieken

• Duidelijke correlatie met oplopende querylatentie

Op dat moment was Postgres CPU-gebonden. Queries duurden langer, blokkeerden andere queries en de latentie verspreidde zich door het hele systeem.

Tijdlijn (UTC)

• 15:30 – Automatische waarschuwingen voor hoge DB-belasting. Eerste diagnostiek toonde verhoogde DELETE-activiteit op APIv2.

• 15:49 – We hebben de DELETE-rate limits aangescherpt om de directe druk te verminderen.

• 16:03 – Verdere analyse toonde dat het verkeer normaal was. De databasebelasting bleef toenemen.

• 16:06 – Eerste meldingen van Enterprise-klanten die eventtypes niet konden laden.

• 16:18 – Incident uitgeroepen. CPU-verzadiging zorgde ervoor dat statementlatentie in het hele systeem toenam.

• 17:07 – We begonnen met het herschrijven van een query met hoge belasting om de druk op de database te verminderen.

• 17:40 – Queryherschrijving uitgerold. Dit hielp, maar loste het probleem niet volledig op.

Het cruciale keerpunt

Om 17:45 identificeerden we een onbedoelde interactie:
Een recente functie die op maandag de 26e was uitgebracht, introduceerde een zoekfunctie voor boekingen binnen KBar (CMD+K). Hierdoor werd bij elke paginalading in de webapp een zware API-aanroep uitgevoerd.
Om 17:55 werd de KBar-wijziging in productie teruggedraaid.

Wat deze grafiek bevestigt:

• Een duidelijke en onmiddellijke daling in AAS na het terugdraaien

• De querydruk op de database nam af

• De latentie stabiliseerde kort daarna

Dit komt precies overeen met het tijdstip van terugdraaien en bevestigde de KBar-interactie als de primaire trigger van het database-incident.

• 18:15 – De databaseprestaties stabiliseerden.
  Het primaire DB-incident was op dat moment opgelost.

Ontdekte secundaire problemen

Na het herstel van de database bleef een kleinere groep gebruikers getroffen.
Gebruikers met Google Calendar-integraties ondervonden fouten door uitputting van het Google API-quotum. Dit werd veroorzaakt door retry-gedrag over meerdere consumers terwijl upstream-fouten optraden.

Wat deze grafiek laat zien:

• Snelle quota-opname tijdens het incidentvenster

• Correlatie met retry-gedrag in plaats van nieuw verkeer

• 18:40 – Oorzaak vastgesteld: Atoms retry-logica ververst kalendergegevens agressief.

• 18:46 – De Atoms-functionaliteit werd tijdelijk onderbroken. Kalendergebeurtenissen werden aangevuld en het quotagebruik daalde.

• 18:54 – De prestaties van APIv2 bleven licht gedegradeerd; een deel van het verkeer werd tijdelijk omgeleid naar Vercel-endpoints.

• 19:30 – APIv2 en Google-integraties waren volledig gestabiliseerd.

Later identificeerden we nog een extra bijdragend probleem:

• Een niet-afgewachte, naar een promise omgezette aanroep zorgde ervoor dat Node-processen crashten wanneer Google API-fouten in de globale scope terechtkwamen.

Hoofdoorzaak

De primaire oorzaak was een onverwachte interactie tussen functies:

• KBar activeerde bij elke paginalading een zware API-aanroep

• Dat API-pad was afhankelijk van dure databasequery's; met name voor grootschalige gebruikers met veel boekingen.

• CPU-verzadiging verhoogde de querylatentie in het hele systeem

• Enterprise-klanten met eventtypes met hoog volume werden het hardst getroffen

Secundaire storingen (uitputting van Google-quota en instabiliteit van APIv2) waren niet de oorspronkelijke oorzaak, maar kwamen aan het licht zodra het systeem onder druk stond.

Wat we hebben veranderd

Sinds dinsdag hebben we:

• De koppeling met KBar verwijderd die zware API-aanroepen triggerde (#27314)

• Meerdere query-optimalisaties uitgerold om de DB-belasting te verminderen (#27364, #27319, #27309, #27315)

• De paginering voor /booking/{upcoming,…} gewijzigd van vooraf gerenderd naar op aanvraag, waardoor het databasegebruik afneemt terwijl we het endpoint blijven optimaliseren (#27351)

• De niet-afgewachte async-aanroep gefixt die Node-process-crashes veroorzaakte in APIv2(#27313)

• Verschillende waarborgen op DB-niveau geïmplementeerd om onze database te beschermen tijdens perioden van extreem gebruik.

• Aanroepen naar DELETE-endpoints beperkt tot 1 verzoek per seconde (#27359)

Afsluiting

Dit incident werd niet veroorzaakt door verkeerspieken of infrastructuuruitval. Het werd veroorzaakt door een onverwachte interactie tussen functies, met domino-effectproblemen door retry-gedrag stroomafwaarts en een subtiele applicatiefout.

Onze excuses voor de verstoring, vooral voor klanten die op schaal opereren. Het incident van dinsdag heeft direct geleid tot verbeteringen in hoe we functies uitrollen, onze database beschermen en cascaderende storingen afhandelen.

Dank voor uw geduld, en dat u ons aan een hoge standaard houdt.