Så fort ett system växer dyker frågan upp: ska tjänster och delar prata direkt med varandra, eller via meddelanden? Köer är ett av de mäktigaste verktygen i en arkitekts verktygslåda – men också ett av de lättaste att missbruka. Här är en praktisk genomgång av när de är rätt, och vad de kostar.
Synkront blir snabbt skört
När tjänst A anropar tjänst B direkt och väntar på svar, är A helt beroende av att B är uppe, snabb och felfri just i det ögonblicket. Lägg till tjänst C och D i kedjan, så blir hela flödet lika svagt som sin svagaste länk. Ett tillfälligt fel långt ned fortplantar sig hela vägen upp till användaren.
Med en meddelandekö vänder vi på logiken: producenten lägger en händelse i kön och går vidare direkt. Konsumenterna plockar upp händelsen när de har möjlighet. Delarna frikopplas, och systemet som helhet blir betydligt mer motståndskraftigt.
Vad köer ger dig
Den största vinsten är frikoppling. En enda ”order skapad”-händelse kan trigga fakturering, lageruppdatering och bekräftelsemejl – var och en helt oberoende, utan att ordertjänsten ens vet att de finns. Vill du lägga till en ny funktion imorgon? Lägg till en konsument till. Producenten rörs inte.
Konkreta fördelar i vardagen:
- Buffert vid trafiktoppar – kön jämnar ut belastningen
- Automatiska omförsök när ett tillfälligt fel uppstår
- Nya konsumenter kan läggas till utan att röra befintlig kod
- Tunga uppgifter flyttas ur användarens väntan och körs i bakgrunden
Priset du betalar
Asynkronitet är inte gratis. Meddelanden kan komma i fel ordning, eller levereras mer än en gång. Därför måste konsumenterna vara idempotenta – att bearbeta samma meddelande två gånger ska ge samma resultat som en gång.
Felsökning blir också svårare, eftersom flödet inte längre är en rak linje du kan följa i en stacktrace. Bra loggning och distribuerad spårning är inte ett tillval här – det är ett krav.
Vanliga fallgropar
Den vanligaste misstaget är att lägga allt i köer ”för säkerhets skull”. Då bygger du en svårfelsökt labyrint av indirektion för flöden som hade mått bra av ett enkelt, synkront anrop. Använd köer där de tillför något konkret – inte som standard.
Glöm inte heller hanteringen av meddelanden som aldrig går att bearbeta. En ”dead letter queue” för dessa är skillnaden mellan ett system du litar på och ett som tyst tappar data.
Sammanfattning
Använd köer när uppgifter kan ske i bakgrunden, när delar behöver skalas olika, eller när du vill frikoppla team och tjänster från varandra. Behåll det synkront när användaren måste få ett direkt svar. Som med all arkitektur: rätt verktyg till rätt problem, inte det senaste verktyget till alla problem.