Webhooks eller polling?

Hvordan finder ét system ud af at der er sket noget i et andet? Der findes to grundlæggende svar, og valget mellem dem påvirker både hvad integrationen koster at køre og hvor friske dataene er. Det ene er at spørge hele tiden: polling. Det andet er at få besked: webhooks. Forskellen lyder lille, men får store konsekvenser, og det gælder om at forstå hvad hver af dem koster før man vælger.

De to mønstre

Polling betyder at jeres system med jævne mellemrum spørger et andet: Er der kommet noget nyt? Måske hvert femte minut, måske hver time. Systemet spørger uanset om svaret er ja eller nej, og langt de fleste gange er svaret nej.

Webhooks vender hele forholdet om. I stedet for at I spørger, giver det andet system selv besked i samme øjeblik noget sker. En ordre bliver lagt, en betaling går igennem, en aftale bliver underskrevet, og et lille kald sendes direkte til jer. I behøver ikke spørge, for I får besked.

Et billede fra hverdagen: Polling er at gå ud til postkassen hvert femte minut for at se om posten er kommet. Webhooks er at have en dørklokke der ringer når der faktisk bliver leveret noget. Det ene koster konstante ture til ingen nytte, det andet venter til der er grund til at reagere.

Pollingens skjulte omkostning

Polling ser enkelt ud, og det er netop enkelheden der skjuler regningen. Omkostningen er sjældent en post på fakturaen; den ligger i tre ting.

• Unødvendige kald. Spørger I hvert femte minut, men sker der kun noget et par gange om dagen, er næsten alle kald spildt. I belaster både jeres eget og det andet system for svaret “intet nyt”.
• Forsinkelse. En hændelse opdages først ved næste forespørgsel. Med et interval på fem minutter kan dataene være op til fem minutter gamle før I overhovedet ved at de findes. Til noget tidsfølsomt er det for trægt.
• Grænser for kald. Mange tjenester begrænser hvor ofte I må spørge. Poller I ofte for at holde dataene friske, risikerer I at ramme loftet og blive midlertidigt lukket ude.

I kan mindske forsinkelsen ved at spørge oftere, men så stiger de unødvendige kald og risikoen for at ramme grænserne. I kan mindske antallet af kald ved at spørge sjældnere, men så bliver dataene mere forældede. Polling tvinger et kompromis frem som webhooks slipper for.

Webhookens svage punkt

Webhooks løser både friskheden og de unødvendige kald, men flytter problemet et andet sted hen. Prisen hedder usikker levering.

Når I selv spørger, har I kontrollen. Kom svaret ikke frem, spørger I igen. Med webhooks er I i stedet afhængige af at afsenderen når frem til jer, og her kan meget gå galt. Jeres modtager kan være nede lige når kaldet bliver sendt. Kaldet kan gå tabt undervejs. Det kan komme til at blive sendt to gange. Til forskel fra polling, hvor I styrer tempoet, er I prisgivet en anden parts evne til at levere i det rigtige øjeblik.

Det gør ikke webhooks uegnede, men det betyder at de skal bygges med omhu for at blive pålidelige. En naivt bygget webhook-modtager der antager at hvert kald kommer frem præcis én gang, vil før eller siden overse eller dobbeltbogføre noget.

Mønstrene der gør webhooks pålidelige

Tre mønstre går igen når webhooks bygges til at holde i virkeligheden:

• Retries (genforsøg). Afsenderen bør prøve igen hvis modtageren ikke svarer, gerne med stigende mellemrum. Så overlever flowet et kort nedbrud hos jer.
• Idempotens. Modtageren skal kunne tåle at få den samme hændelse flere gange uden at gøre noget to gange. Genkender den en hændelse den allerede har håndteret, ignorerer den dubletten. Det er det der gør genforsøg ufarlige.
• Kvitteringer. Modtageren bekræfter tydeligt at en hændelse er modtaget. Udebliver kvitteringen, ved afsenderen at den skal prøve igen. Uden kvittering ved ingen om kaldet kom frem.

Tilsammen forvandler de webhooks fra noget skrøbeligt til noget robust: Hændelser der kommer frem sent, to gange eller efter et nedbrud, bliver alligevel håndteret korrekt.

Når polling alligevel er det rigtige

Trods omkostningerne er polling nogle gange det rigtige valg. Det tydeligste tilfælde er når systemet I integrerer med, simpelthen ikke tilbyder webhooks: Så er der intet at vælge imellem. Polling passer også til batch-logik: Skal I alligevel kun hente alt nyt en gang om natten eller i timen, betyder de unødvendige kald og forsinkelsen ingenting. Er volumen lav og friskhed uden betydning, kan polling være både enklere og helt tilstrækkeligt.

Tommelfingerreglen: Vælg webhooks når de findes og friskhed betyder noget, men byg dem med retries, idempotens og kvitteringer. Nøjes med polling når webhooks mangler eller når batch er nok. Vi hos Weapp bygger integrationer efter begge mønstre og hjælper med at vælge det rigtige til hvert flow. Se vores ydelser eller kontakt os.