Dobbelte e-mails fra samtidige

Når en virksomhed skalerer sine automatiseringer, sætter man typisk flere workers til at behandle den samme kø parallelt. Det giver mening rent kapacitetsmæssigt, men det åbner samtidig en race condition: to workers kan begge læse det samme job fra køen, inden nogen af dem har nået at markere det som taget. Resultatet er, at kunden modtager samme ordrebekræftelse, samme rykker eller samme velkomstmail to gange.

Det er ikke en teoretisk risiko. Det sker, i det øjeblik trafikken eller belastningen stiger nok til, at to processer rammer den samme kø inden for millisekunder af hinanden. Jo mere en virksomhed automatiserer sin kommunikation med AI-drevne flows, jo større bliver overfladen for netop den slags fejl, fordi flere job bliver sendt gennem flere parallelle workers på kortere tid.

Den nye dispatcher angriber problemet arkitektonisk i stedet for at lappe symptomerne. Den bygger på tre principper, som tilsammen sikrer, at et job kun kan udføres én gang, uanset hvor mange workers der forsøger at tage det:

- Idempotent enqueue, så det samme job aldrig kan lægges dobbelt i køen - Atomisk claiming, så kun én worker kan vinde retten til at behandle et givent job - Klar afgrænsning af, hvad løsningen ikke garanterer, så teams ved præcis hvor deres eget ansvar begynder

Det sidste punkt er værd at bemærke i sig selv. En arkitektur, der ærligt fortæller, hvad den ikke løser, er mere brugbar end en, der lover for meget.

Idempotent enqueue betyder, at et job kun kan tilføjes til køen én gang, selvom det forsøges lagt ind flere gange. Det løses typisk ved, at hvert job får en unik nøgle, ofte afledt af selve handlingen, for eksempel ordre-id plus mail-type. Når systemet forsøger at lægge et job i køen, tjekker det først, om nøglen allerede findes. Hvis den gør, ignoreres det nye forsøg stiltiende.

Det lyder trivielt, men det er ofte her, fejl sniger sig ind i praksis. En webhook, der fyrer to gange på grund af et netværksudfald, eller en bruger, der dobbeltklikker på en knap, kan begge udløse det samme job to gange, hvis køen ikke selv beskytter sig mod det. Idempotent enqueue flytter det ansvar ind i selve infrastrukturen i stedet for at lade det ligge hos den enkelte udvikler, der skriver kaldet.

Selv med en ren kø kan to workers stadig læse det samme job, hvis de spørger køen om arbejde på samme tid. Løsningen på det er atomisk claiming: når en worker vil tage et job, sker det gennem en enkelt, udelelig databaseoperation, der samtidig markerer jobbet som taget. Den anden worker, der spørger millisekunder senere, får simpelthen at vide, at jobbet allerede er taget, og går videre til det næste.

Det er den samme grundmekanik, man kender fra lagerstyring eller billetsalg, hvor systemet skal garantere, at kun én kunde kan reservere den sidste plads. Princippet er ikke nyt, men det er ofte det første, teams glemmer, når de bygger deres første AI-drevne automatisering i fart. Man tester med én worker, det virker, og man opdager først problemet, når belastningen stiger, og en anden worker kommer ind i billedet.

Der er en grænse for, hvad selv en velbygget dispatcher kan garantere. Hvis en worker crasher, efter den har claimet et job, men før selve e-mailen er sendt, opstår et nyt spørgsmål: er jobbet nu tabt, eller skal det gives til en anden worker, med risiko for at mailen alligevel sendes to gange, hvis den første worker faktisk nåede at sende, inden den crashede?

Det er et grundlæggende dilemma i distribuerede systemer, kendt som "at-least-once versus exactly-once" levering, og ingen dispatcher løser det fuldstændigt uden en form for kvittering fra selve afsendelsessystemet. Den ærlige konklusion er, at atomisk claiming løser problemet med samtidige workers, der begge griber efter det samme job fra start, men ikke problemet med en worker, der fejler midtvejs i eksekveringen. Det kræver en separat mekanisme, typisk en bekræftet leveringsstatus fra selve mailudbyderen, før jobbet betragtes som endeligt afsluttet.

Som selvstændig AI-konsulent for små og mellemstore virksomheder arbejder jeg ofte med ledere, der er i gang med at automatisere kundekommunikation for første gang, ofte gennem AI-drevne workflows der trigger e-mails, notifikationer eller opfølgninger. Den mest almindelige fejl, jeg ser, er ikke at fejle med teknologien, men at underkende, hvor hurtigt selv et lille automatiseringsflow kan ramme skalaproblemer, i det øjeblik det bliver sat op med mere end én worker for at holde svartiden nede.