Kö, event eller webhook? En beslutsmatris utan jargon

Kö, event eller webhook? En beslutsmatris utan jargon

Att välja transportsätt handlar i grunden om ansvar och risk. Vem lovar vad, till vem, och med vilka konsekvenser om något missas? När det blir tydligt är valet sällan tekniskt svårt. Nedan får du de tre begreppen i klartext, följt av en praktisk beslutsdel och två konkreta case.

Tre begrepp – förklarade utan teknikprat

Kö
Tänk “att-göra-lista” där varje uppgift plockas av en arbetare. Bra när något måste utföras (skapa order i ERP, generera faktura), när ordningen spelar roll, och när du vill kunna pausa, kvotstyra och ta igen backlog.
En kö hjälper dig att jämna ut toppar och hålla mottagaren trygg även när inflödet varierar. Du får naturliga mätpunkter (hur mycket väntar, hur snabbt betas det av) och kan återköra utan handpåläggning. Det kostar lite mer att sätta upp — men du får kontroll.

Event
En anslagstavla där du sätter upp “Order skickad”. Många kan läsa lappen, ingen måste göra något — men flera kan reagera (notifiera kund, uppdatera analytics, trigga returpolicy). Perfekt för “flera mottagare behöver veta”.
Event passar när du vill möjliggöra nya konsumenter utan att röra källsystemet. Du decouplar och framtidssäkrar. Nackdelen är att event i sig inte garanterar att något blir gjort; det är en signal, inte en arbetsorder.

Webhook
En ringklocka: “Ping! Något hände.” Du skickar ett HTTP-samtal till någon annans adress. Snabbt och enkelt, men du äger inte mottagarens drift. Bra för ekosystem och partnerkopplingar – om du planerar för tidsgränser, retrys och dubbletter.
Webhookar är utmärkta när du vill vara enkel för andra att integrera mot. Bygg alltid med signaturer, tidsstämplar och återförsök — internet är opålitligt på riktigt.

Besluta rätt med 5 raka frågor

Det effektivaste sättet att undvika fel val är att ställa samma få frågor varje gång. Det ger en stabil vana och gör att teamet tar samma beslut även när personerna skiftar.

1) Måste något utföras – eller räcker det att veta?

• Måste utföras ⇒ Kö (garanterad handläggning, återförsök, backpressure).

• Räcker att veta ⇒ Event (fan-out till många, svagt kopplad arkitektur).

2) Har du en eller många mottagare?

• En mottagare ⇒ Kö.

• Flera nu – eller kanske senare ⇒ Event (låt fler prenumerera utan att ändra källan).

3) Behöver ordning och exakt-en-gång?

• Ja ⇒ Kö (idempotens + ordningskrav hanteras lättast här).

• Nej ⇒ Event eller Webhook.

4) Äger du båda sidor eller ska du nå en partner?

• Eget ekosystem ⇒ Kö/Event internt.

• Extern part ⇒ Webhook ut, gärna med signering, retrys och dead-letter-logik.

5) Hur känslig är mottagaren för last?

• Känslig/kvotbegränsad ⇒ Kö framför mottagaren (throttling).

• Tål broadcast ⇒ Event; för externa, “smalna av” via en gateway/webhook-distributör.

Poängen med frågorna är inte att bli 100 % “rätt” från dag ett, utan att minimera felbeslut som blir dyra att ändra. Du kan byta mönster senare — men välj det som bäst speglar ansvarsfördelningen här och nu.

Snabb “om-så”-guide (ingen tabell, bara beslut)

Listan nedan fungerar bra i backloggen, som små beslutskort. Den gör det enkelt att vara konsekvent även när farten är hög.

• Om en order måste skapas i affärssystemet så: skicka till kö.

• Om flera team vill reagera på “order skickad” så: publicera event.

• Om en 3-part vill bli pingad när lagersaldo ändras så: skicka webhook (med signatur + återförsök).

• Om du inte vet vilka konsumenter som finns om sex månader så: välj event (framtidssäkert).

• Om mottagaren ofta stryps av kvoter så: lägg kö framför och dränera i lagom takt.

• Om samma sak ibland råkar skickas två gånger så: gör konsumenten idempotent (oavsett mönster).

Två konkreta case

Case A: Order → ERP
Här krävs utförande, ordning och felhantering. Lägg ordern på kö. Konsumenten skapar ordern i ERP, loggar kvitto, och vid fel försöker den om med backoff. Fastnar något hamnar det i en felkö där ni kan trycka “spela om” utan manuell rekonstruktion. Resultat: inga dubbletter, inga tappade ordrar, lugn support.
I praktiken brukar det här korta MTTR rejält vid ERP-störningar. Ni ser precis vilka ordrar som väntar, hur långt de kom, och kan köra om kontrollerat efter en incident. Ekonomiskt betyder det färre handpåläggningar och färre kompensationer till kund. Framför allt blir det förutsägbart: även när något fallerar vet ni vad nästa steg är.

Case B: Lagerändring → flera kanaler
En ändring ska nå webb, marknadsföring och ett par partners. Publicera event “InventoryUpdated”. Interna system prenumererar direkt. Externa partners nås via en webhook-distributör som tar emot eventet, kör kvotstyrning, signerar anrop och hanterar retrys. Resultat: du byter, lägger till eller pausar konsumenter utan att röra källsystemet.
Det här gör också att ni kan rulla ut förändringar i flera steg. Lägg till en ny kanal, verifiera i skuggläge, skala upp när den beter sig bra. Eventet är er hållpunkt — konsumenter får utvecklas i sin takt utan att skapa kedjereaktioner.

Den enda punktlistan: Fördelar när du väljer rätt mönster

• Färre produktionsincidenter: rätt transport minskar dubbletter, tapp och timeouts.

• Kortare tid till leverans: du slipper ad-hoc-fixar när nya mottagare tillkommer.

• Lägre kostnad över tid: event låter dig återanvända samma signal till fler syften; köer kapar handpåläggning.

• Bättre partnerupplevelse: webhookar med signering och retrys gör att samarbeten flyter.

• Mätbarhet: köer/event ger naturliga mätpunkter för ledtid, fel och backpressure.

Fördelarna ovan kommer inte från “mer teknik”, utan av att ansvaret blir tydligt. När alla vet vad som garanteras (och inte) försvinner mycket av bruset som annars stjäl tid.

Vanliga fallgropar (och hur du undviker dem)

• Webhook utan retrys. Nätet krånglar. Skicka om med backoff och tidsstämplar.

• Event som kravbärare. Om något måste hända är det inte ett event, det är en uppgift ⇒ lägg det på kö.

• “Allt i en webhook.” Du blir hårt kopplad till mottagarens SLA. Sätt en mellanlandning (kö/gateway) som buffrar och signerar.

• Ingen idempotens. Oavsett mönster: skydda med unika nycklar (order-ID, versionsnummer) så att dubbletter inte gör skada.

• Otydligt ansvar. Skriv “producent/consument-kontrakt” i klartext: vad skickas, när skickas det, hur länge sparas, hur kvitteras?

De här misstagen är vanliga för att de känns snabbare i stunden. Betalningen kommer senare i form av felsökning och manuellt stök. Att göra rätt från början är inte dyrt — det är disciplin och några få standarder.

Styrning utan överarbete

Håll tre enkla mått per flöde: ledtid (från signal till reaktion), fel/1000 meddelanden och manuella återkörningar/vecka. När siffrorna pekar rätt vet du att mönstret bär. Om inte – byt, innan du skalar.
Sätt en låg tröskel för visualisering: en enkel dashboard duger. Det viktiga är förändring över tid, inte perfekta tal. Börja med en baseline, följ upp veckovis, och koppla mätningen till beslut — vad slutar vi göra när en siffra går ner, och vad investerar vi i när den går upp?

Checklista innan du bestämmer dig (kort, praktisk)

• Vad måste hända, och vad räcker att “någon kanske gör”?

• Hur många konsumenter finns idag – och imorgon?

• Klarar mottagaren toppar, eller behöver vi buffra/strypa?

• Vilken idempotensnyckel använder vi?

• Hur mäter vi ledtid och fel?

Använd checklistan i PR-beskrivningar eller ärendebeskrivningar. Den tar sekunder att fylla, men sparar timmar i efterhand eftersom valet blir spårbart.

Sammanfattning

• Kö = uppgifter som måste genomföras, med ordning, återförsök och kvotstyrning.

• Event = händelser som många kan reagera på, utan krav på utförande.

• Webhook = ping till externa, snabbt och enkelt — men bygg skyddsräcken.

Välj mönster efter ansvar, mottagare och risk, inte efter vana. Gör du det rätt får du färre störningar, snabbare förändringstakt och lägre kostnad när du lägger till nya flöden.

Läs mer

• SonarQube: Från godtycklig kodgranskning till mätbar kvalitet i varje release
• Vad gör en DevOps – i praktiken
• Seniorkonsult på Sparkhouse