Event-Driven Architecture auf AWS: Praktische Muster mit SNS, SQS, Lambda und EventBridge – was wir aus „Event Driven Architecture in AWS“ von Walter Huber (KaWa commerce GmbH) mitgenommen haben

Kontext: Warum ereignisgesteuert – und warum jetzt?

Auf der DevJobs.at-Redaktionsbank verfolgen wir aufmerksam, wie sich Softwarearchitekturen von monolithischen Anwendungen zu verteilten Systemen entwickeln. In der Session „Event Driven Architecture in AWS“ von Walter Huber (KaWa commerce GmbH) wurde genau dieser Übergang greifbar: weg vom großen Monolithen hin zu Microservices, die über klar definierte Schnittstellen miteinander sprechen – zunehmend asynchron und serverlos.

Gleich zu Beginn ordnete Huber die Rolle seines Unternehmens ein: KaWa commerce GmbH arbeitet als AWS Advanced Consulting Partner in Österreich mit starkem Fokus auf Event-Driven-Architekturen und Microservices, inklusive Zertifizierungen (Solution Architect, DevOps, Cloud Practitioner) und als Solution Provider. Das unterstreicht die Praxisnähe der Beispiele, die in der Session folgten.

Von Monolith zu Microservices: Das Problemfeld

Die Evolution der Service-Architektur: Früher bündelte ein Monolith sämtliche Funktionen, Logik und Datenzugriffe in einer Codebasis. Inzwischen verteilen viele Teams Verantwortung auf kleinere Services – mit eigener API, eigener Service-Architektur, eigenem Team und oft auch eigener Datenbank.

Was ist ein Microservice? Huber beschreibt ihn als organisatorischen Ansatz der Softwareentwicklung, bei dem Software aus kleinen, unabhängigen Services besteht, die über gut definierte APIs kommunizieren. Jeder Service löst einen kleinen, klar umrissenen Teil der Gesamtaufgabe „und macht diesen gut“, kann für sich skalieren und bleibt austauschbar.

Wesentlich ist die Abkehr von starren, direkten Kopplungen. Statt dass alles synchron per API miteinander spricht, kommen asynchrone Muster ins Spiel – Events statt Request/Response. Genau hier setzt Event-Driven Architecture an.

Synchron vs. Asynchron: Konsequenzen für Latenz und Fehlertoleranz

Das synchrone Muster – wenn alles gleichzeitig klappen muss

Synchron heißt: Ein Service stellt eine Anfrage und wartet auf die Antwort. Das ist für viele APIs sinnvoll, gerade wenn schnelle, einfache Abfragen mit Caching ausreichen. Huber machte aber die Tücken deutlich – vor allem im Backend, wenn komplexe Logik dahinterliegt. Ein Beispiel aus dem E‑Commerce: Das Anlegen einer Bestellung kann weitere Dienste triggern, etwa fünf Backend-Services, die Informationen abrufen oder aktualisieren.

• Latenz addiert sich: Wenn einer dieser Dienste 200 Millisekunden benötigt, summiert sich das – in Hubers Beispiel auf rund eine Sekunde – bevor überhaupt eine Antwort zurückkommt.
• Fehler propagieren sich: Fällt ein einzelner Dienst aus, kann die gesamte synchrone Kette scheitern. Der anfragende Service muss Fehlerbehandlung übernehmen – und im Zweifel scheitert der Gesamt-Request.

Das asynchrone Muster – entkoppeln, puffern, fortsetzen

Asynchron bedeutet: Ein Service veröffentlicht ein Ereignis („eine Nachricht“) und macht erst einmal weiter. Abnehmende Dienste holen sich die Information, sobald sie bereit sind. Der Publisher blockiert nicht und bleibt unabhängig von der Erreichbarkeit der Konsumenten.

Huber zeigt, dass diese Entkopplung die Fehlertoleranz erhöht und Skalierung erleichtert: Wenn ein nachgelagerter Dienst gerade nicht verfügbar ist oder gewartet wird, gehen Nachrichten nicht verloren, sondern werden gepuffert und später verarbeitet.

Message Broker im Überblick – und die AWS-Perspektive

In der IT-Landschaft sind Message-Broker etabliert, etwa Apache Kafka, RabbitMQ oder neuere Pub/Sub-Funktionen in Redis. Sie bieten einen Event-Bus, in den Publisher Nachrichten einstellen, die Abonnenten erhalten.

Die Herausforderung: Betrieb und Skalierung. Cluster müssen installiert, gepatcht, aktualisiert werden; Lastspitzen und Hochverfügbarkeit sind zu managen. Hubers Fazit: Das sind robuste Werkzeuge, aber der Betriebsaufwand ist real – besonders beim Skalieren.

AWS bietet dazu mehrere verwaltete Bausteine, die den Betrieb abnehmen und nativ mit Serverless-Ansätzen zusammenspielen. Genau diese Bausteine strukturierte Huber im Talk.

AWS Lambda: Reagieren auf Ereignisse – und automatisch skalieren

Lambda ist „nur ein Stück Code“, das durch ein Event ausgelöst wird, Daten verarbeitet und ein Ergebnis wegspeichert oder weiterleitet. Die Stärke: automatische Skalierung. Huber brachte ein prägnantes Bild: Ob einmal pro Sekunde oder 100.000 Mal pro Sekunde – Lambda skaliert mit.

Ein anschauliches Beispiel: Bildverarbeitung. Ein Event signalisiert, dass ein Bild verfügbar ist. Eine Lambda-Funktion liest das Bild, skaliert es, schreibt Varianten in einen S3‑Bucket und beendet sich. Keine Serververwaltung, keine manuelle Skalierung – AWS übernimmt das.

Für Event-Driven-Architektur ist Lambda damit ein natürlicher Konsument oder Verarbeiter von Nachrichten – leichtgewichtig, kosteneffizient („pay only what you need“) und hoch skalierbar.

Pub/Sub auf AWS: Amazon SNS für Themen, Amazon SQS für Puffer

Amazon SNS: Themenbasiertes Verteilen

Mit Amazon SNS (Simple Notification Service) können Publisher Ereignisse an ein Topic senden. Abonnenten – Dienste, die diese Information benötigen – bekommen die Nachricht. Hubers E‑Commerce-Beispiel: „Neue Bestellung“ wird an ein SNS‑Topic veröffentlicht, alle relevanten Services (etwa Auslieferung, Kundenservice, Abrechnung) abonnieren dieses Topic und reagieren.

SNS entkoppelt Sender und Empfänger: Der Publisher muss nicht wissen, wer konsumiert. Er „verkündet“ das Event – und SNS verteilt.

Amazon SQS: Warteschlangen für robuste Verarbeitung

SNS allein ist bei Ausfällen oder Wartungsfenstern nicht genug – Nachrichten könnten verloren gehen, wenn ein Empfänger temporär nicht erreicht wird. Deshalb kombiniert Huber SNS mit SQS (Simple Queue Service):

• Fan‑out: Ein SNS‑Topic kann auf mehrere SQS‑Warteschlangen „fächern“. Jeder nachgelagerte Dienst verarbeitet aus der eigenen Queue.
• Pufferung: Wenn ein Konsument im Wartungsfenster ist oder temporär nicht laufen kann, bleiben Nachrichten in seiner SQS‑Warteschlange liegen und werden später verarbeitet.
• Drosselung: Hinter einer Queue kann ein Dienst bewusst nur so viele Nachrichten verarbeiten, wie seine Abhängigkeiten (z. B. eine Datenbank mit begrenzten Verbindungen) zulassen. Huber nannte das Beispiel, eine Flut von 1.000 Nachrichten pro Sekunde auf 100 pro Sekunde zu begrenzen – Batch‑Weise aus SQS gezogen, ohne die nachgelagerte Datenbank zu überlasten.

Die Kombination aus SNS (Themen verteilen) und SQS (puffern, drosseln) ist damit ein „message broker“-Muster in AWS – verwaltet, hochverfügbar und ohne eigenen Clusterbetrieb.

Dead-Letter-Queues und „Poison Messages“ im Blick behalten

Auch das kam in der Session zur Sprache: Nachrichten, die dauerhaft nicht verarbeitet werden können („poison messages“), sollten in eine Dead-Letter-Queue (DLQ) umgeleitet werden. Überwachung ist hier Pflicht – wächst die DLQ an, stimmt etwas in der Verarbeitung nicht.

EventBridge: Der Event-Bus für AWS-Services und eigene Events

AWS EventBridge ergänzt SNS/SQS um ein flexibleres, regelbasiertes Routing – inklusive tiefer Integration mit Cloud‑Events der AWS-Umgebung. Huber hob zwei Aspekte hervor:

• Interne AWS-Ereignisse: Änderungen in der AWS‑Umgebung – etwa das Erstellen einer EC2‑Instanz oder Änderungen an RDS – werden als Events in EventBridge sichtbar und können verarbeitet werden.
• Eigene Events: Externe Services bzw. Anwendungen können benutzerdefinierte Ereignisse in EventBridge publizieren. EventBridge verteilt diese an passende Ziele.

Damit verhält sich EventBridge „wie ein Kafka“ – ein Message-Bus, der Ereignisse entgegennimmt und an „Subscribers“ weiterleitet. Der Unterschied: vollständig verwaltet und tief im AWS‑Ökosystem verankert.

AWS Step Functions: Orchestrieren, wenn mehrere Services zusammenwirken

Nicht alles lässt sich rein durch lose Kopplung lösen. Manche Prozesse benötigen einen Orchestrierer, der den Gesamtfluss kennt und einen Abschluss melden kann. Huber nannte als Beispiel die Order‑Verarbeitung:

• Bestellung erzeugt ein Event.
• Mehrere Services – etwa Lieferung und Kundenservice – reagieren und arbeiten parallel oder sequenziell.
• Erst wenn alle Schritte erledigt sind, soll ein finaler Status („alles fertig“) an einen weiteren Dienst gemeldet werden.

Step Functions übernehmen diese Orchestrierung und können eine Abschlussmeldung auslösen, sobald alle definierten Schritte abgeschlossen sind. Gerade in Microservice-Landschaften vermeidet man damit implizite Kopplung und behält trotzdem einen verlässlichen End‑to‑End‑Status.

Observability und Betrieb: X-Ray und CloudWatch

Mit steigender Anzahl von Microservices wächst die Notwendigkeit, die Gesamtheit sichtbar zu machen. Huber warnte davor, „die Übersicht zu verlieren“ – und zeigte zwei Bausteine:

• AWS X‑Ray: Durch Instrumentierung im Code werden Verbindungen und Aufrufe zwischen Services sichtbar. So lässt sich nachvollziehen, „wo der Traffic hingeht“, wo Latenzen entstehen und wo Probleme auftreten.
• Amazon CloudWatch: Der Klassiker für Logs und Metriken. Wichtig, um Queue‑Längen zu beobachten, Alarme zu setzen (z. B. wachsende DLQs), Dashboards aufzubauen und die Betriebsstabilität im Blick zu behalten.

Ohne diese Transparenz bleibt eine Event‑Driven‑Architektur im Blindflug – mit ihnen lässt sich schnell erkennen, wo die Architektur skaliert und wo Engpässe entstehen.

Kostenmodell und Skalierung: „Pay only what you need“

Ein wiederkehrendes Motiv war das Kostenmodell: In AWS zahlt man nur, was man nutzt. Huber stellte das gegenüber: 100 Requests kosten entsprechend wenig, 100.000 Requests entsprechend mehr – aber ohne Vorhaltung von Serverkapazitäten, die im Leerlauf teuer wären. Das gilt insbesondere für Lambda und das ereignisgetriebene Zusammenspiel mit SNS/SQS/EventBridge.

Gleichzeitig skaliert jeder Service „in seinem eigenen Tempo“. Kann ein Dienst nur 100 Nachrichten pro Sekunde verarbeiten, dann verarbeitet er 100 – dank SQS‑Puffer läuft die Gesamtverarbeitung dennoch stabil weiter. Ein Ausfall eines Teilsystems führt nicht mehr zum Systemausfall: Nachrichten bleiben in Queues, bis der Dienst wieder da ist.

Ein praktisches Bild: Order‑Flows im E‑Commerce

Hubers Beispiele drehten sich mehrfach um E‑Commerce, wo Order‑Events häufig Auslöser für viele nachgelagerte Schritte sind. Die Kerngedanken lassen sich auf viele Domänen übertragen:

• Ein Service publiziert das Ereignis „Neue Bestellung“ in SNS oder EventBridge.
• Mehrere Konsumenten (Lieferung, Kundenservice, Abrechnung, Reporting) abonnieren das Event, jeder mit eigener SQS‑Queue.
• Temporäre Ausfälle oder Wartungsfenster einzelner Dienste sind unkritisch – die Queue puffert.
• Schrittketten, die einen finalen Abschluss melden sollen, werden mit Step Functions orchestriert.
• Lambda‑Funktionen verarbeiten Events elastisch – ob wenige pro Sekunde oder sehr viele.
• X‑Ray und CloudWatch liefern Transparenz über Flüsse, Fehler, DLQs und Queue‑Längen.

Das Muster ist simpel, aber mächtig: Ereignisse statt synchroner Ketten, Puffer statt Timeouts, Orchestrierung statt impliziter Kopplung.

Orchestrierung bleibt eine Herausforderung – mit Werkzeugen lösbar

Huber sprach Orchestrierung explizit als Herausforderung an. In ereignisgetriebenen Landschaften kann es schwer sein, den Überblick zu behalten, wo welcher Prozess steht und wann „alles fertig“ ist. Step Functions adressieren genau das. Zusätzlich erwähnte er das Serverless Application Model (SAM) als Framework, um serverlose Anwendungen in AWS im großen Maßstab zu bauen und zu deployen.

Die Botschaft: Architektur führt – Tools folgen. Mit SAM, Step Functions, X‑Ray und CloudWatch existiert ein Set, das Gestaltung, Betrieb und Sichtbarkeit vereint.

Leitplanken und bewährte Muster (aus der Session abgeleitet)

Ohne über das Gesagte hinauszugehen, lassen sich aus Hubers Punkten klare Leitplanken ableiten:

• Entkopplung per SNS+SQS: SNS verteilt Ereignisse, SQS puffert und erlaubt Drosselung – ideal, um Services voneinander zu isolieren.
• Asynchron vor Synchron: Wo synchrone Abhängigkeiten Latenz addieren oder die Gesamtstabilität gefährden, Events bevorzugen.
• Wartungsfenster einplanen: SQS als Puffer verhindert Datenverlust und Backpressure, wenn Konsumenten temporär ausfallen.
• Orchestrieren, wo nötig: Für „Alles‑fertig“-Signale Step Functions nutzen.
• Sichtbarkeit zwingend: X‑Ray für Fluss‑Transparenz, CloudWatch für Logs, Metriken und Alarme (inkl. DLQs).
• Kosten im Griff: Serverless und „pay only what you need“ begünstigen kosteneffiziente Architekturen – auch wenn Lastspitzen auftreten.

Handlungsempfehlungen für den Einstieg

Folgt man dem Pfad, den Huber skizziert, lässt sich eine erste Event‑Driven‑Landschaft in AWS pragmatisch aufbauen:

1. Ereignisse identifizieren: Welche Domänenereignisse fallen an (z. B. „Neue Bestellung“)?
2. Topics und Queues definieren: Ein SNS‑Topic je Ereignis, eine SQS‑Queue je Konsumentendienst.
3. Verarbeitung kapseln: Pro Queue eine Lambda‑Funktion, die Events verarbeitet – mit Batch‑Größen passend zur Zielsystemkapazität (Drosselung).
4. Orchestrierte Flows modellieren: Wo ein Abschluss benötigt wird, eine Step‑Functions‑State‑Machine definieren.
5. Beobachtbarkeit aktivieren: X‑Ray in die Services integrieren; CloudWatch‑Metriken und Alarme für Queue‑Längen, Fehler und DLQs einrichten.
6. Deployment standardisieren: Mit dem Serverless Application Model (SAM) die Infrastruktur und Funktionen definieren und deployen.

Diese Schritte sind deckungsgleich mit dem, was Huber im Talk hervorhob – ohne zusätzlichen Betriebsballast eigener Broker‑Cluster.

Klarer Nutzen – klarer Fokus

Am Ende seiner Session fasste Huber zusammen, warum die ereignisgesteuerte Architektur überzeugt:

• Jeder Service skaliert unabhängig.
• Nicht die gesamte Kette fällt aus, wenn ein Teil ausfällt.
• Kosten bleiben proportional zur Nutzung – von 100 bis 100.000 Requests.
• Orchestrierung ist machbar, wenn man die passenden Werkzeuge einsetzt.

Das ist kein Selbstzweck, sondern die Antwort auf reale Latenz‑, Kopplungs‑ und Betriebsprobleme in modernen verteilten Systemen.

Ausblick und Recruiting-Hinweis

Zum Abschluss wies Huber darauf hin, dass KaWa commerce GmbH aktiv nach Serverless‑Anwendungsentwickler:innen sucht – mit aktuellen Jobangeboten auf der DevJobs.at‑Plattform. Wer sich für Event‑Driven‑Architekturen in AWS interessiert, findet hier also nicht nur einen technischen Pfad, sondern auch eine konkrete Gelegenheit, diese Ideen in die Praxis zu bringen.

Key Takeaways (aus „Event Driven Architecture in AWS“ von Walter Huber)

• Microservices profitieren stark von asynchroner Kommunikation: weniger Kopplung, mehr Robustheit.
• SNS+SQS ist in AWS ein pragmatisches Broker‑Muster: Fan‑out, Puffer und Drosselung inklusive.
• EventBridge ergänzt um regelbasiertes Routing und tiefe AWS‑Integration – plus benutzerdefinierte Events.
• Lambda liefert elastische Verarbeitung – vom Einzelereignis bis zu sehr hohen Raten.
• Step Functions orchestrieren Ende‑zu‑Ende‑Flows, wenn ein finaler Status benötigt wird.
• X‑Ray und CloudWatch sind unverzichtbar, um Flüsse, Fehler und DLQs im Blick zu behalten.
• „Pay only what you need“ macht EDA auf AWS kosteneffizient – unabhängig von Lastspitzen.

So verdichtet sich Hubers Botschaft: Wer von synchronen, fragilen Ketten auf ein robustes, entkoppeltes Ereignis‑Design umstellt, gewinnt Skalierbarkeit, Fehlertoleranz und Betriebssicherheit – mit verwalteten Bausteinen, die sich nahtlos in AWS fügen.

• 

  

  Walter Huber, CTO von KaWa commerce

  Der CTO von KaWa commerce Walter Huber gibt im Interview Einblicke in die Möglichkeiten zur Weiterentwicklung im Unternehmen, was beim Recruiting im Vordergrund steht und wie die Projekte technologisch umgesetzt werden.

  Jetzt ansehen