Postmortem: 23 minutter forsinkede webhooks 12. september

12. september mellom 10:41 og 11:04 ble webhooks for hendelsene faktura.* og signering.* levert med opptil 23 minutters forsinkelse. Ingen hendelser gikk tapt, og API-et svarte normalt hele tiden. Vi beklager forsinkelsen og forklarer her hva som skjedde.

Oppsummering

Hva skjedde

Webhooks i Spire går gjennom en Kafka-kø med 48 partisjoner. Hver hendelse får en partisjonsnøkkel, og hendelser med samme nøkkel havner i samme partisjon, slik at rekkefølgen per kunde bevares. Nøkkelen har til nå vært kunde_id.

Klokken 10:38 rullet vi ut en endring som skulle gi strengere rekkefølge per objekt (for eksempel alle hendelser for samme faktura i rekkefølge). Nøkkelen ble endret til kunde_id + objekt_type. Det var riktig tenkt, men i koden ble objekt_type satt til produktnavnet, ikke objekt-ID-en. Resultatet var at alle fakturahendelser for alle kunder fikk nøkkelen faktura, og alle signeringshendelser fikk signering. To partisjoner tok imot det som skulle vært spredt på 48.

Én konsument per partisjon leverer webhooks med maks 50 samtidige HTTP-kall. Når én partisjon får 24 ganger normal trafikk, bygger køen seg opp. Forsinkelsen vokste jevnt til 23 minutter på det meste.

Hvorfor tok det 23 minutter

• 10:47: Varsel på leveringsforsinkelse. Vakthavende startet undersøkelse.
• 10:52: Bekreftet at API-et var friskt og at køen vokste på to partisjoner. Mistanke om utrullingen fra 10:38.
• 10:55: Besluttet å rulle tilbake. Tilbakerullingen tok fire minutter fordi den gikk gjennom samme kanariprosess som vanlige utrullinger.
• 10:59: Ny kode produserte hendelser med riktig nøkkel. De to fulle partisjonene måtte likevel tømmes av sine to konsumenter.
• 11:04: Køen var tom. Forsinkelse tilbake under 2 sekunder.

Hva vi har endret

1. Test på partisjonsfordeling. Utrullingspipelinen sjekker nå fordelingen av nøkler i en prøve på 10 000 hendelser og stopper hvis noen partisjon får over 10 prosent.
2. Raskere tilbakerulling for webhook-tjenesten. Tilbakerulling hopper over kanari-trinnet. Det er trygt fordi forrige versjon allerede har kjørt i produksjon.
3. Elastisk konsument. Når en partisjon har over 5 000 hendelser i kø, starter vi midlertidige konsumenter som leverer uten rekkefølgegaranti for hendelser som har passert 60 sekunder. Vi mener 60 sekunder gammel rekkefølge er mindre viktig enn 20 minutter forsinkelse. Dette er dokumentert under webhooks.
4. Statussiden viser nå webhook-forsinkelse som egen komponent, ikke bare «Webhooks: i drift».

Hva du bør gjøre

Ingenting, hvis integrasjonen din er bygget etter dokumentasjonen: webhooks er idempotente, hver hendelse har id og opprettet, og du kan alltid hente gjeldende tilstand med GET. Hvis du har bygget logikk som antar at en webhook kommer innen n sekunder etter hendelsen, bør du lese om håndtering av forsinkelse.

Spørsmål om hendelsen kan sendes via kontaktskjemaet med emnet «Teknisk spørsmål». Vi svarer på alle.