Incidentreview: databasebelasting, cascaderende storingen en wat we hebben geleerd - 27 januari 2026

Impact

• Gebruikers met weinig volume ervoeren hoge latentie en trage laadtijden van pagina’s

• Enterprise-klanten met veelgebruikte scheduling links ervoeren time-outs en downtime

• 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 voor verhoogde databasebelasting. Uit de eerste analyse bleek dat Average Active Sessions (AAS) toenam en de statement-latency snel opliep, terwijl het totale verkeer binnen de verwachte grenzen bleef.

Wat deze grafiek laat zien:

• Een aanhoudende toename van actieve databasesessies

• Sessies die zich opstapelden in plaats van snel af te ronden

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

Dit wees op een wijziging in onze applicatie in plaats van een verkeerspiek, wat verkeersanalyse bevestigde.

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 uitkomt

• Aanhoudende verzadiging in plaats van korte pieken

• Duidelijke correlatie met oplopende querylatentie

Op dat moment was Postgres CPU-bound. Queries liepen langer, blokkeerden andere en de latentie verspreidde zich door het systeem.

Tijdlijn (UTC)

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

• 15:49 – We hebben de DELETE-ratelimieten aangescherpt om de directe druk te verlagen.

• 16:03 – Verder onderzoek liet zien dat het verkeer normaal was. De databasebelasting bleef toenemen.

• 16:06 – Eerste meldingen van enterprise-klanten die scheduling links niet konden laden.

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

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

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

Het belangrijkste kantelpunt

Om 17:45 identificeerden we een onbedoelde interactie:
Een recente feature die op maandag de 26e werd gelanceerd, introduceerde booking search in KBar (CMD+K). Daardoor werd bij elke paginalading in de webapp een zware API-call uitgevoerd.
Om 17:55 werd de KBar-wijziging in productie teruggedraaid.

Wat deze grafiek bevestigt:

• Een duidelijke en directe daling van AAS na de rollback

• Minder druk op databasequeries

• Kort daarna stabiliserende latentie

Dit komt precies overeen met het moment van de rollback en bevestigde de KBar-interactie als de belangrijkste trigger van het database-incident.

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

Secundaire problemen aan het licht gebracht

Nadat de database hersteld was, bleef een kleinere groep gebruikers getroffen.
Gebruikers met Google Calendar-integraties ondervonden storingen door uitgeputte Google API-quota. Dit werd veroorzaakt door retry-gedrag over meerdere consumers terwijl upstreamfouten optraden.

Wat deze grafiek laat zien:

• Snelle quota-opname tijdens het incidentvenster

• Correlatie met retry-gedrag in plaats van nieuw verkeer

• 18:40 – Root cause vastgesteld: Atoms retry-logica die kalenders agressief ververste.

• 18:46 – Atoms-functionaliteit werd tijdelijk onderbroken. Calendar events werden aangevuld en het quota-verbruik daalde.

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

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

Later stelden we nog een extra bijdragend probleem vast:

• Een niet-afgewachte, ge-promisifyde call zorgde ervoor dat Node-processen crashten wanneer Google API-fouten naar de globale scope doorsijpelden.

Root cause

De primaire oorzaak was een onverwachte interactie tussen features:

• KBar triggerde bij elke paginalading een zware API-call

• Dat API-pad was afhankelijk van dure databasequeries; vooral voor gebruikers op grote schaal met veel bookings.

• CPU-verzadiging verhoogde de querylatentie door het hele systeem

• Enterprise-klanten met veelgebruikte scheduling links werden het hardst getroffen

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

Wat we hebben veranderd

Sinds dinsdag hebben we:

• De KBar-koppeling verwijderd die zware API-calls 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 on-demand, waardoor het databasegebruik afneemt terwijl we het endpoint verder optimaliseren (#27351)

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

• Verschillende veiligheidsmaatregelen op DB-niveau ingesteld om onze database te beschermen tijdens perioden van extreem gebruik.

• Calls naar DELETE-endpoints geratelimiteerd tot 1 request per seconde (#27359)

Afsluiting

Dit incident werd niet veroorzaakt door verkeerspieken of een storing in de infrastructuur. Het werd veroorzaakt door een onverwachte feature-interactie, met cascaderende problemen door retry-gedrag downstream en een subtiele applicatiebug.

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

Bedankt voor je geduld, en dat je ons aan zo’n hoge standaard houdt.