Webhooks eller polling?

Hur får ett system reda på att något hänt i ett annat? Det finns två grundläggande svar, och valet mellan dem påverkar både vad integrationen kostar att köra och hur färsk datan blir. Det ena är att fråga hela tiden – polling. Det andra är att bli tillsagd – webhooks. Skillnaden låter liten men får stora konsekvenser, och det gäller att förstå vad var och en kostar innan man väljer.

De två mönstren

Polling betyder att ert system med jämna mellanrum frågar ett annat: har det kommit något nytt? Kanske var femte minut, kanske varje timme. Systemet frågar oavsett om svaret är ja eller nej, och de allra flesta gångerna är svaret nej.

Webhooks vänder på hela relationen. I stället för att ni frågar, meddelar det andra systemet er självmant i samma stund något händer. En order läggs, en betalning går igenom, ett avtal signeras – och ett litet anrop skickas direkt till er. Ni behöver inte fråga, för ni blir tillsagda.

En vardaglig bild: polling är att gå till brevlådan var femte minut för att se om posten kommit. Webhooks är att ha en dörrklocka som ringer när något faktiskt levereras. Det ena kostar ständiga turer i onödan, det andra väntar tills det finns skäl att reagera.

Pollingens dolda kostnad

Polling ser enkelt ut, och det är just enkelheten som döljer notan. Kostnaden är sällan en post på fakturan – den sitter i tre saker.

• Onödiga anrop. Frågar ni var femte minut men något händer bara ett par gånger om dagen, är nästan alla anrop bortkastade. Ni belastar både ert och det andra systemet för svaret “inget nytt”.
• Fördröjning. En händelse upptäcks först vid nästa fråga. Med fem minuters intervall kan datan vara upp till fem minuter gammal innan ni ens vet om den. För något tidskänsligt är det för trögt.
• Gränser för anrop. Många tjänster begränsar hur ofta ni får fråga. Pollar ni tätt för att hålla datan färsk riskerar ni att slå i taket och bli tillfälligt avstängda.

Ni kan minska fördröjningen genom att fråga oftare, men då ökar de onödiga anropen och risken att slå i gränserna. Ni kan minska anropen genom att fråga mer sällan, men då blir datan tröttare. Polling tvingar fram en kompromiss som webhooks slipper.

Webhookens svaga punkt

Webhooks löser både färskheten och de onödiga anropen – men flyttar problemet någon annanstans. Priset heter leveransosäkerhet.

När ni själva frågar har ni kontroll. Kom svaret inte fram frågar ni igen. Med webhooks är ni i stället beroende av att avsändaren når fram till er, och där kan mycket gå fel. Er mottagare kan vara nere just när anropet skickas. Anropet kan tappas på vägen. Det kan råka skickas två gånger. Till skillnad från polling, där ni styr takten, är ni utlämnade åt att någon annan lyckas leverera i rätt ögonblick.

Det gör inte webhooks olämpliga – men det betyder att de måste byggas med omsorg för att bli pålitliga. En naivt byggd webhook-mottagare som antar att varje anrop kommer fram exakt en gång kommer förr eller senare att missa eller dubbelbokföra något.

Robusthetsmönstren som gör webhooks pålitliga

Tre mönster återkommer när webhooks byggs för att hålla i verkligheten:

• Retries (omförsök). Avsändaren bör försöka igen om mottagaren inte svarar, gärna med ökande mellanrum. Då överlever flödet ett kort avbrott hos er.
• Idempotens. Mottagaren måste tåla att få samma händelse flera gånger utan att göra något dubbelt. Känner den igen en händelse den redan hanterat, ignorerar den dubbletten. Det är vad som gör omförsök ofarliga.
• Kvittenser. Mottagaren bekräftar tydligt att en händelse tagits emot. Uteblir kvittensen vet avsändaren att den ska försöka igen. Utan kvittens vet ingen om anropet gick fram.

Tillsammans förvandlar de webhooks från något bräckligt till något robust: händelser som kan komma fram sent, dubbelt eller efter ett avbrott hanteras ändå rätt.

När polling ändå är rätt

Trots kostnaderna är polling ibland det riktiga valet. Det tydligaste fallet är att systemet ni integrerar mot helt enkelt inte erbjuder webhooks – då finns inget att välja på. Polling passar också batch-logik: ska ni ändå bara hämta allt nytt en gång per natt eller per timme, spelar de onödiga anropen och fördröjningen ingen roll. Är volymen låg och färskhet oviktig kan polling vara både enklare och fullt tillräckligt.

Tumregeln: välj webhooks när det finns och färskhet betyder något, men bygg dem med retries, idempotens och kvittenser. Nöj dig med polling när webhooks saknas eller när batch räcker. Vi på Weapp bygger integrationer på båda mönstren och hjälper till att välja rätt för varje flöde. Titta på våra tjänster eller hör av dig.