Webhooks eller polling?

Hvordan får et system vite at noe har skjedd i et annet? Det finnes to grunnleggende svar, og valget mellom dem påvirker både hva det koster å kjøre integrasjonen og hvor ferske dataene blir. Det ene er å spørre hele tiden, altså polling. Det andre er å få beskjed, altså webhooks. Forskjellen høres liten ut, men får store konsekvenser, og det gjelder å forstå hva hver av dem koster før man velger.

De to mønstrene

Polling betyr at systemet deres med jevne mellomrom spør et annet: Har det kommet noe nytt? Kanskje hvert femte minutt, kanskje hver time. Systemet spør uansett om svaret er ja eller nei, og de aller fleste gangene er svaret nei.

Webhooks snur hele forholdet. I stedet for at dere spør, gir det andre systemet dere beskjed på eget initiativ i det øyeblikket noe skjer. En ordre legges inn, en betaling går gjennom, en avtale signeres, og et lite kall sendes rett til dere. Dere trenger ikke å spørre, for dere får beskjed.

Et bilde fra hverdagen: Polling er å gå til postkassen hvert femte minutt for å se om posten har kommet. Webhooks er å ha en dørklokke som ringer når noe faktisk blir levert. Det ene koster stadige turer til ingen nytte, det andre venter til det er grunn til å reagere.

Den skjulte kostnaden ved polling

Polling ser enkelt ut, og det er nettopp enkelheten som skjuler regningen. Kostnaden er sjelden en post på fakturaen. Den ligger i tre ting.

• Unødvendige kall. Spør dere hvert femte minutt, men noe skjer bare et par ganger om dagen, er nesten alle kallene bortkastet. Dere belaster både deres eget og det andre systemet for svaret «ingenting nytt».
• Forsinkelse. En hendelse oppdages først ved neste spørring. Med fem minutters intervall kan dataene være opptil fem minutter gamle før dere i det hele tatt vet om dem. For noe tidskritisk er det for tregt.
• Grenser for antall kall. Mange tjenester begrenser hvor ofte dere får spørre. Poller dere tett for å holde dataene ferske, risikerer dere å nå taket og bli midlertidig stengt ute.

Dere kan redusere forsinkelsen ved å spørre oftere, men da øker de unødvendige kallene og risikoen for å nå grensene. Dere kan redusere antall kall ved å spørre sjeldnere, men da blir dataene mindre ferske. Polling tvinger frem et kompromiss som webhooks slipper.

Det svake punktet ved webhooks

Webhooks løser både ferskheten og de unødvendige kallene, men flytter problemet til et annet sted. Prisen heter leveranseusikkerhet.

Når dere spør selv, har dere kontroll. Kom ikke svaret frem, spør dere igjen. Med webhooks er dere i stedet avhengige av at avsenderen når frem til dere, og der kan mye gå galt. Mottakeren deres kan være nede akkurat når kallet sendes. Kallet kan gå tapt på veien. Det kan bli sendt to ganger ved et uhell. I motsetning til polling, der dere styrer takten, er dere prisgitt at noen andre klarer å levere i riktig øyeblikk.

Det gjør ikke webhooks uegnede, men det betyr at de må bygges med omhu for å bli pålitelige. En naivt bygget webhook-mottaker som antar at hvert kall kommer frem nøyaktig én gang, kommer før eller senere til å gå glipp av noe eller bokføre noe dobbelt.

Mønstrene som gjør webhooks pålitelige

Tre mønstre går igjen når webhooks bygges for å tåle virkeligheten:

• Retries (nye forsøk). Avsenderen bør prøve igjen hvis mottakeren ikke svarer, gjerne med økende mellomrom. Da overlever dataflyten et kort avbrudd hos dere.
• Idempotens. Mottakeren må tåle å få den samme hendelsen flere ganger uten å gjøre noe dobbelt. Kjenner den igjen en hendelse den allerede har håndtert, ignorerer den duplikatet. Det er dette som gjør nye forsøk ufarlige.
• Kvitteringer. Mottakeren bekrefter tydelig at en hendelse er mottatt. Uteblir kvitteringen, vet avsenderen at den skal prøve igjen. Uten kvittering vet ingen om kallet kom frem.

Til sammen forvandler de webhooks fra noe skjørt til noe robust: Hendelser som kommer frem sent, dobbelt eller etter et avbrudd, blir likevel håndtert riktig.

Når polling likevel er riktig

Til tross for kostnadene er polling iblant det riktige valget. Det tydeligste tilfellet er at systemet dere integrerer mot, rett og slett ikke tilbyr webhooks. Da finnes det ingenting å velge mellom. Polling passer også til batchlogikk: Skal dere uansett bare hente alt nytt én gang per natt eller per time, spiller de unødvendige kallene og forsinkelsen ingen rolle. Er volumet lavt og ferskhet uviktig, kan polling være både enklere og helt tilstrekkelig.

Tommelfingerregelen: Velg webhooks når de er tilgjengelige og ferskhet betyr noe, men bygg dem med retries, idempotens og kvitteringer. Nøy deg med polling når webhooks mangler eller batch holder. Vi i Weapp bygger integrasjoner etter begge mønstrene og hjelper til med å velge riktig for hver dataflyt. Se tjenestene våre eller ta kontakt.