Frakobl alt. Lad services kommunikere gennem begivenheder, ikke forventninger om hinandens oppetid.

Din monolit er ved at blive en flaskehals i udrulningen — hver ændring kræver koordination på tværs af teams, og en fejl i fakturering nedlægger hele applikationen. Eller du bygger et nyt system, hvor forskellige funktioner udvikler sig i forskelligt tempo: ordrestyring ændrer sig ugentligt, men lagerlogikken ændrer sig kvartalsvis. Du har brug for services, der kan udvikles, udrulles og skaleres uafhængigt, og som kommunikerer gennem begivenheder snarere end synkrone API-kald, der skaber kaskader af fejl.
Explore more design patterns and system architectures
Vores arkitekter kan hjælpe dig med at designe og bygge systemer ved hjælp af dette mønster til dine specifikke krav.
Kom i KontaktEvent-driven microservices dekomponerer et system til uafhængigt deploybare services, der primært kommunikerer gennem asynkrone begivenheder. Hver service ejer sine data, publicerer domænebegivenheder, når tilstanden ændrer sig, og reagerer på begivenheder fra andre services. Dette eliminerer tidsmæssig kobling — Service A behøver ikke Service B til at køre for at udføre sit arbejde. Mønstret inkorporerer CQRS (Command Query Responsibility Segregation) for at adskille skrive- og læsemodeller, event sourcing for at fange hele historikken for tilstandsændringer og saga orchestration for at administrere transaktioner på tværs af flere services uden distribuerede låse.
Arkitekturen centrerer sig om en event backbone (Kafka, EventBridge eller NATS), der router domænebegivenheder mellem services. Hver service har tre grænser: en command handler, der behandler indkommende anmodninger og udsender begivenheder, en query handler, der serverer læseoptimerede projektioner, og en event processor, der reagerer på begivenheder fra andre services. En saga orchestrator koordinerer forretningsprocesser i flere trin (f.eks. ordreudførelse) ved at lytte efter begivenheder og udsende kompenserende kommandoer, når trin fejler.
| Lag | Teknologier |
|---|---|
| Compute | Node.js (NestJS), Python (FastAPI), Go — per service baseret på workload-karakteristika |
| Messaging | Apache Kafka (MSK), AWS EventBridge, NATS JetStream, RabbitMQ |
| Data | PostgreSQL (transactional), DynamoDB (key-value), Redis (caching/locks), EventStoreDB |
| Orchestration | Temporal (workflow orchestration), AWS Step Functions, custom saga coordinator |
| Observability | OpenTelemetry (distributed tracing), Datadog, Jaeger, structured logging med correlation IDs |
| Brug når | Undgå når |
|---|---|
| Flere teams skal udrulle uafhængigt med forskellige kadencer | Dit team er < 5 ingeniører — en velstruktureret monolit er enklere at drive |
| Forskellige dele af systemet har forskellige skaleringskarakteristika | Du bygger en MVP og skal lancere hurtigt — distribuerede systemer er langsomme at bygge |
| Du har brug for stærke audit trails og event replay-funktioner | Hver operation kræver synkrone, stærkt konsistente svar |
| Domænet har naturlige bounded contexts (ordrer, betalinger, lager) | Domænet er tæt koblet — at splitte det skaber en distribueret monolit |
MW dekomponerer ikke i microservices efter teknisk lag (API service, data service, auth service). Vi dekomponerer langs domænegrænser ved hjælp af DDD (Domain-Driven Design) bounded contexts. Før vi skriver kode, afholder vi en event storming workshop for at kortlægge domænebegivenheder, kommandoer og aggregater — dette bestemmer servicegrænser, ikke teknologipræferencer. Vi har migreret monolitter til event-drevne arkitekturer for enterprise-kunder, og den mest almindelige lektion er: start med færre, større services og split senere, ikke omvendt.
Modeller kører ikke sig selv. Den pipeline, der træner, validerer, implementerer og overvåger dine modeller, er det egentlige produkt – modellen er blot ét artefakt.
MicrocosmWorks designer event-driven systemer med holdbare message brokers som Apache Kafka eller Amazon EventBridge, der beholder events, indtil forbrugere har behandlet dem succesfuldt, hvilket sikrer intet datatab under nedbrud. Vi implementerer dead-letter queues, exponential backoff retry policies og circuit breakers, så en fejlerende microservice ikke blokerer hele event pipeline. Når den downstream service genopretter sig, indhenter den automatisk ubehandlede events uden manuel indgriben.
Event-drevet kommunikation er det bedste valg, når dine services ikke behøver et øjeblikkeligt svar, når du har brug for at afkoble deployment-cyklusser, eller når en enkelt handling udløser flere efterfølgende processer. MicrocosmWorks anbefaler typisk event-drevne mønstre til ordrebehandling, notifikationspipelines og analyseindtagelse, samtidig med at synkrone API'er bevares til brugerrettede forespørgsler, der kræver svar på under et sekund. Mange produktionssystemer, vi bygger, anvender en hybrid tilgang med synkrone læsninger og asynkrone skrivninger.
MicrocosmWorks bruger partitionsnøgle-baseret rækkefølge i Kafka-emner for at garantere, at alle begivenheder for en given entitet (som en specifik ordre eller bruger) behandles sekventielt af den samme forbrugerinstans. For scenarier, der kræver rækkefølge på tværs af entiteter, implementerer vi saga orchestrators med idempotente begivenhedshandlere, der sikkert kan genbehandle meddelelser uden for rækkefølge. Vi indlejrer også vektorklokker eller sekvensnumre i begivenhedsnyttelast, så forbrugere kan opdage og afstemme rækkefølgekonflikter.
MicrocosmWorks implementerer Saga pattern med kompenserende transaktioner, hvor hver mikroservice udgiver domænebegivenheder efter at have gennemført sin lokale transaktion, og downstream services reagerer i overensstemmelse hermed eller udløser rollback-kompensationer ved fejl. Vi kombinerer dette med et outbox pattern, der atomisk skriver begivenheder til en lokal outbox-tabel sammen med forretningsdata og derefter pålideligt publicerer dem til message brokeren. Dette opnår eventual consistency uden ydelses- og pålidelighedsstraf fra two-phase commits.
MicrocosmWorks instrumenterer hver hændelse med correlation IDs og distributed tracing headers ved hjælp af OpenTelemetry, hvilket giver os mulighed for at visualisere den komplette livscyklus for en business transaction på tværs af alle deltagende microservices i værktøjer som Jaeger eller Grafana Tempo. Vi bygger også realtids-dashboards for event flow, der viser throughput, consumer lag og processing latency per service, hvilket gør det nemt at identificere flaskehalse. Vores standard observability stack inkluderer structured logging med event metadata, så enhver enkelt hændelse kan spores fra producer til hver consumer på få sekunder.