Händelsedriven arkitektur (EDA) är ett sätt att bygga programvara där delar av ett system kommunicerar genom att tillkännage att något har hänt, i stället för att anropa varandra direkt. En komponent publicerar en händelse, till exempel ”faktura betald” eller ”avtal undertecknat”. Alla andra komponenter som berörs reagerar på den. Ingen av sidorna behöver veta att den andra finns.

För ett SaaS-bolag spelar detta roll långt utanför utvecklingsavdelningen. Samma idé ligger bakom rena överlämningar från CRM till ekonomi, pålitlig automatisering och AI-agenter som agerar på aktuella data. Den här guiden förklarar hur EDA fungerar, hur en händelsebuss skiljer sig från en kö, hur man undviker de vanliga felen och var den hör hemma och inte hör hemma.

Kort sagt

Innehållsförteckning

Vad händelsedriven arkitektur är

Microsofts arkitekturvägledning beskriver stilen som händelseproducenter som genererar en ström av händelser, händelsekonsumenter som lyssnar efter dem och händelsekanaler som för händelser från den ena till den andra. Den tredelade modellen är hela idén. Allt annat är detaljer om hur pålitligt och hur snabbt kanalen fungerar.

Motsatsen är begäran och svar. I en design med begäran och svar anropar din faktureringstjänst ditt CRM och väntar på ett svar. Om CRM-systemet är långsamt eller ligger nere fastnar faktureringen. I en händelsedriven design publicerar faktureringen ”betalning mottagen” och går vidare. CRM-systemet, intäktsrapporten och dashboarden för kundframgång plockar upp händelsen när de är redo.

Två egenskaper följer av detta:

Vad som räknas som en händelse

En händelse är ett påstående om fakta i förfluten tid. Red Hat beskriver den som en oföränderlig post om att något har hänt, ofta med en tidsstämpel som bevarar ordningen i förhållande till det system som skapade den. Du redigerar inte en händelse i efterhand. Om något ändras registrerar en ny händelse ändringen.

AWS noterar att händelser kan vara en tillståndsändring eller en uppdatering, och att de antingen kan bära tillstånd eller vara identifierare. Två exempel:

Stil Exempel Vad konsumenten får
Händelse som bär tillstånd Prenumeration uppgraderad, med plan, pris, ikraftträdandedatum och konto-ID Allt som behövs för att agera utan ytterligare uppslag
Händelse som identifierare Order skickad, med enbart order-ID En signal. Konsumenten hämtar detaljerna från källsystemet

Den första är bekväm men kopplar konsumenterna till händelsens form. Den andra håller händelserna små men skickar konsumenterna tillbaka till källsystemet, vilket väcker frågan om vilket system som är det auktoritativa. Vi återkommer till det nedan, eftersom det är där de flesta SaaS-bolags operativa system har det svårt.

Ett kommando är inte en händelse. ”Skicka fakturan” är en instruktion till en specifik mottagare. ”Faktura skickad” är ett faktum som vem som helst kan reagera på. Att blanda ihop de två är ett vanligt designfel och bygger i det tysta upp den täta koppling som du försökte bli av med.

Så fungerar ett händelsedrivet system, steg för steg

Google Clouds dokumentation beskriver flödet: producenter genererar händelser, en router eller broker tar emot och filtrerar dem och distribuerar dem sedan vidare till konsumenter utifrån prenumerationer eller triggers. I praktiken:

  1. Något inträffar. En affär flyttas till ”Closed Won” i CRM-systemet.
  2. Producenten publicerar en händelse. Den anger fakta och den post som den gäller.
  3. Mäklaren dirigerar den. Den filtrerar händelsen och levererar den till varje prenumerant.
  4. Konsumenterna reagerar oberoende av varandra. Ekonomi skapar ett fakturautkast. Customer Success öppnar en onboardingplan. En provisioneringsprocess förbereder åtkomst.
  5. Varje konsument bekräftar. Mäklaren vet att händelsen har hanterats och kan försöka igen om den inte har gjort det.

IBM beskriver samma mönster som publicering, insamling, bearbetning och lagring av händelser och påpekar att en händelses värde kan förändras över tid. En händelse av typen ”ny lead” är värd att agera på inom några minuter. Ett år senare är den främst användbar för analys.

Händelsedriven arkitektur och mikrotjänster

Man behandlar ofta dessa som samma sak. Det är de inte. Mikrotjänster beskriver hur man delar upp en applikation i små, oberoende driftsatta tjänster. EDA beskriver hur dessa tjänster kommunicerar. Man kan ha mikrotjänster som anropar varandra synkront, och man kan ha en monolit som publicerar händelser internt.

De två fungerar bra tillsammans. Googles vägledning konstaterar att mikrotjänster kan reagera asynkront på händelser och bara behöver känna till händelseformatet, inte varandras affärslogik. Det gemensamma formatet är kontraktet. Allt bakom det kan förändras.

Microsofts dokumentation beskriver det typiska mönstret som mikrotjänster som publicerar en händelse när något anmärkningsvärt inträffar, medan andra mikrotjänster prenumererar.

Händelsebuss, kö eller ström

Dessa tre begrepp skapar mest förvirring, och valet påverkar hur ditt system beter sig.

Händelsebuss (publish/subscribe). En händelsebuss är en mekanism där publicerare tillkännager händelser och prenumeranter tar emot dem. Microsoft förklarar att den kan implementeras på meddelandeinfrastruktur som en kö eller service bus som stöder asynkron publish/subscribe. En kö kan alltså vara en av byggstenarna i en buss. Bussen är avsikten. Kön är ett sätt att förverkliga den.

Kö. En kö håller meddelanden tills en arbetare hämtar dem. Varje meddelande hanteras normalt av en konsument. Köer är rätt verktyg för att fördela arbete mellan arbetare och för att absorbera toppar. Azures integrationsvägledning nämner att köa meddelanden när ett backend inte är tillgängligt som en anledning att använda en broker.

Händelseström. Azure skiljer mellan publish/subscribe och streaming. I publish/subscribe sparas en händelse inte i en beständig logg när den väl har tagits emot, så nya prenumeranter ser inte tidigare händelser. I streaming skrivs händelser till en logg som är beständig och strikt ordnad inom en partition, och klienter läser från loggen och kan ansluta när som helst och spela upp händelser igen.

Kö Publish/subscribe-buss Händelseström
Leverans En konsument per meddelande Varje prenumerant Valfri läsare, från valfri punkt
Tidigare händelser Tas bort efter bearbetning Inte tillgängliga för nya prenumeranter Sparas och kan spelas upp igen
Typisk användning Arbetsfördelning, buffring Underrätta flera system Historik, analys, återuppbyggnad av tillstånd

En praktisk tumregel: om flera system ska reagera på samma fakta, använd publish/subscribe. Om en arbetare ska utföra ett jobb, använd en kö. Om du behöver historik eller möjlighet att bygga om ett efterföljande system, använd en ström. Red Hat tillägger att det inte finns någon lösning som passar alla, så välj teknik utifrån händelsetyp.

Är Kafka en händelsedriven arkitektur?

Nej. Kafka är en teknik som du kan använda för att bygga en sådan. Dokumentationen för Apache Kafka beskriver den som en plattform för händelsestreaming: att fånga händelser i realtid, lagra dem beständigt, bearbeta dem och dirigera dem vidare till andra system. Det gör den till en händelseström i tabellen ovan.

En arkitektur är en uppsättning designbeslut: vilka händelserna är, vem som äger dem, hur konsumenter isoleras och vad som händer vid fel. Du kan fatta dessa beslut och driva dem på en hanterad molnbuss, en kötjänst eller Kafka. Du kan också köra Kafka och ändå ha ett hårt kopplat system om varje tjänst är beroende av en annan tjänsts interna händelser. Välj verktyg först när du har definierat händelserna och den volym du faktiskt förväntar dig.

Händelsedriven integration och automatisering

Här blir EDA relevant för ledare inom verksamheten och inte bara för ingenjörer.

Integration

De flesta SaaS-företag kopplar ihop data från CRM, fakturering, support och produkt med punkt-till-punkt-synkroniseringar. Varje nytt verktyg lägger till ytterligare en anslutning att underhålla. Azure rekommenderar asynkron kommunikation via en meddelandebroker i stället för direkta synkrona anrop, av fyra skäl som anges: frikoppla applikationer, sända till flera konsumenter, spåra långvariga arbetsflöden på ett tillförlitligt sätt och köa meddelanden när ett backend inte är tillgängligt.

Fördelen märks när du lägger till ett system. Med en publish/subscribe-tjänst kan nya prenumeranter läggas till utan att avsändaren uppdateras. Att lägga till ett nytt analysverktyg kräver ingen ändring i ditt CRM.

Automatisering

Händelsedriven automatisering innebär att en affärsprocess startar för att något har hänt, inte för att någon klickade på en knapp eller att ett nattligt jobb kördes. ServiceNows flödesguide ger en praktisk metod: identifiera triggern, planera logiken, välj åtgärderna och identifiera återanvändbar logik. Den rekommenderar också att hålla flöden fokuserade och använda ett verb per åtgärd.

När en process omfattar flera tjänster noterar Microsoft att händelsedrivna system ofta använder koreografi och saga-orkestreringsmönster för att samordna flödet. I koreografi reagerar varje tjänst på händelser och sänder ut sina egna. I orkestrering talar en samordnare om för varje steg vad det ska göra och följer hela processen. I ett första projekt är ett orkestrerat flöde oftast lättare att läsa och granska.

Ett enkelt SaaS-exempel:

Bästa praxis och vanliga utmaningar

Azure listar de viktigaste utmaningarna: eventual consistency, asynkron felhantering, dataförlust, observerbarhet och testning, för många eller alltför sammanslagna händelser samt schemautveckling. Varje utmaning har en motsvarande praxis.

  1. Planera för eventual consistency. System kommer tillfälligt att vara oense. Bestäm vilket system som är auktoritativt för varje faktum och låt de andra följa det.
  2. Inför en dedikerad felhanterare. Misslyckade händelser behöver en plats att hamna på och någon som tittar på dem.
  3. Behåll händelser tills mottagandet har bekräftats. Det skyddar mot dataförlust när en mottagare är nere.
  4. Använd korrelations-ID:n. Ett ID som följer med genom varje steg gör att du kan spåra en enskild kundåtgärd över flera system.
  5. Hitta rätt granularitet på händelserna. En händelse per fältändring skapar brus. En enda jättehändelse för allt skapar åter tät koppling.
  6. Versionshantera scheman tidigt. Händelseformat kommer att ändras. Bestäm hur, innan du har tjugo mottagare.

Till dessa vill vi lägga tre operativa vanor: namnge händelser i förfluten tid, ge varje händelsetyp en ägare och skriv ned vilka mottagare som är beroende av den.

Var händelsedriven design inte hör hemma

EDA är inte svaret på alla problem. Var tydlig med begränsningarna innan du bestämmer dig:

Samma logik gäller för AI. En AI-assistent som läser och agerar i dina system är både konsument och producent av händelser. Om den läser inkonsekvent data eller agerar utan en behörighetsgräns har du ett snabbare sätt att göra fel.

Där detta möter AI-agenter och regelefterlevnad

AI-agenter som hämtar data (frågar, rapporterar, slår upp) och skickar data (uppdaterar en post, startar en process, tilldelar åtkomst) beter sig som deltagare i ett händelsedrivet system. De behöver en tillförlitlig källa att läsa från, en tydlig uppsättning åtgärder de får vidta, godkännande för känsliga steg och en logg över vad de har gjort. En händelselogg är en naturlig plats för den loggen.

Operatör granskar händelseloggen för en AI-agent

För europeiska företag påverkar GDPR, NIS2 och EU AI Act alla hur sådana system utformas. Generellt rör de vilka personuppgifter som flödar genom händelser, hur säkerhet och incidenthantering organiseras samt hur AI-system styrs och dokumenteras. Behandla dem som designunderlag från början och ta juridisk rådgivning av jurist om hur de gäller i just ditt fall. Inget arkitekturval gör i sig ett system regelefterlevande.

Vårt perspektiv

De flesta SaaS-bolag vi pratar med har inget händelseproblem. De har ett ägarskapsproblem. Flera team använder AI, flera verktyg har sin version av kunden och ingen ansvarar för vilken version som är rätt.

Därför arbetar vi i en fast ordning. Först datafundamentet: CRM- och ekonomidata som den överenskomna sanningskällan. Sedan AI-lagret, som kopplar den datan till den assistent som ditt team redan använder. Därefter avdelningsagenter för Finance, Sales och Customer Success. Händelser är användbara i alla tre lagren, men de hjälper först när de fakta de bär på är överenskomna.

Vi inför också en process i taget och börjar med den dyraste. En förnyelseprocess eller en överlämning från faktura till betalning är ett bättre första händelsedrivet projekt än en ombyggnad av hela företaget. Du ser resultatet, ditt team lär sig mönstret och nästa process blir billigare.

Eftersom vi driver verksamhet och inte bara utformar system bryr vi oss om de tråkiga delarna: behörigheter, godkännanden, spårbarhet och en överlämning där du äger koden, dokumentationen och infrastrukturen.

Claus Nielsen

Så kommer du igång i ditt eget företag

Du behöver inte välja broker först. Börja med de här frågorna:

  1. Vilken process kostar dig mest i manuellt arbete, förseningar eller fel?
  2. Vilka två eller tre händelser startar den (till exempel affär avslutad, faktura förfallen, förnyelse närmar sig)?
  3. Vilket system är sanningskällan för datan i de händelserna?
  4. Vem äger varje händelsedefinition?
  5. Vilka steg kräver mänskligt godkännande?

Om du inte kan svara på den tredje frågan kommer datafundamentet först. Om du kan det visar en liten pilot på en process om ett händelsedrivet tillvägagångssätt lönar sig.

Så kan vi hjälpa till

Om ditt team använder AI men ingen äger det kan vi hjälpa dig att avgöra var det lönar sig och bygga det i rätt ordning. Vår AI Readiness Assessment finns från €4,500 och granskar dina data, system och processer innan något byggs. Om du vill ha löpande ledning börjar Fractional Chief AI Officer-avtalet från €1,500 per månad.

Byggen prissätts till 30% av en förstaårsbesparing som är uppmätt och bevisad, eller till ett fast pris som överenskoms innan arbetet startar. Du kan också boka ett kostnadsfritt upptäcktssamtal på 30 minuter via vår webbplats. Våra AI-agenter för Finance, Sales och Customer Success visar hur avdelningslagret ser ut när fundamentet är på plats.

FAQ

Vad är händelsedriven arkitektur i enkla termer?

Det är en design där mjukvarukomponenter meddelar att något har hänt och andra komponenter reagerar. Avsändaren vet inte vem som lyssnar. Det gör att du kan lägga till eller ändra system utan att skriva om dem som producerar händelserna.

Vad är skillnaden mellan en händelsebuss och en meddelandekö?

En kö levererar vanligtvis varje meddelande till en enda arbetare. En händelsebuss levererar varje händelse till alla prenumeranter. En buss kan byggas på köinfrastruktur, så skillnaden ligger i syftet och leveransmönstret, inte alltid i produkten.

Är händelsedriven arkitektur detsamma som mikrotjänster?

Nej. Mikrotjänster handlar om hur en applikation delas upp i tjänster. Händelsedriven arkitektur handlar om hur delarna kommunicerar. De används ofta tillsammans, men var och en kan finnas utan den andra.

När bör ett SaaS-bolag använda händelsestyrd automatisering?

Använd den när en affärsprocess ska starta utifrån ett faktum, till exempel ett avslutat avtal eller en förnyelse som närmar sig, och flera team eller system behöver reagera. Börja med en kostsam process och se till att källdatan är överenskommen först.

Källor