Event-driven Architecture ist in denen Situationen die passende Architektur, in denen eine starke Entkopplung der einzelnen Einheiten gefordert ist. Azure bietet dafür die passende Infrastruktur, verwirrt aber gleichzeitig mit drei möglichen Funktionalitäten: Event Grid, Service Bus und Azure Functions. Welche setzt man nun wann ein?
Sofía Platas bringt es im Interview am Rande der .NET Developer Conference (DDC) auf den Punkt: Event Grid ist wie ein Lautsprecher. Es feuert Events ab – fire and forget – an alle, die zuhören wollen. Perfekt für einfache Notifications.
Service Bus hingegen ist die Warteschlange mit Köpfchen. Hier werden Messages nicht nur durchgereicht, sondern auch verwaltet: Was passiert, wenn ein Consumer abbricht? Die Nachricht geht zurück in die Queue, nicht verloren. Und wenn's eng wird, skalieren mehrere Worker parallel – Stichwort Competing Consumers.
Und Azure Functions? Die sind die kleinen Minions, die zwischen Event Grid und Service Bus hin- und herlaufen, Nachrichten vorbereiten, weiterleiten und dabei automatisch hochskalieren, wenn's drauf ankommt.
Best Practice: Outbox Pattern – Dein Sicherheitsnetz
Einer der Knackpunkte: das Outbox Pattern. Die Idee ist simpel, aber genial: Wenn Du eine Message in die Queue schickst, speicherst Du sie parallel auch noch woanders ab – etwa in einer Datenbank. Wird sie erfolgreich verarbeitet? Super, lösch sie. Schlägt was fehl? Die Message liegt noch in der Outbox, und ein Hintergrundprozess kann sie später nochmal pushen.
Warum das wichtig ist? Stell Dir vor, Du hast einen Webshop. Zehn Bestellungen kommen gleichzeitig rein, Deine API crasht – 500 Internal Server Error. Ohne Queue? Weg sind sie. Mit Service Bus und Outbox Pattern? Alle sicher verwahrt und werden später abgearbeitet.
Azure ist hier besonders deshalb die richtige Wahl, da es alle Technologien bietet. Ein Praxisbeispiel aus einem echten Projekt macht die Vorteile deutlich: Ein Online-Shop startete mit wenigen Bestellungen pro Woche. Kein Problem für synchrone Verarbeitung. Aber beim Skalieren? Plötzlich kamen viele Bestellungen gleichzeitig herein. Eine zwischengeschaltete Service Bus Queue sorgte dafür, dass bei API-Ausfällen keine Bestellung verloren ging – sie landeten einfach in der Dead Letter Queue zur späteren Verarbeitung.
Decoupling: Producer und Consumer kennen sich nicht
Ein großer Vorteil von Event-driven: Entkopplung. Producer und Consumer reden nicht direkt miteinander. Dazwischen liegt ein Broker – bei Azure sind das eben Event Grid, Event Hub oder Service Bus. Die Systeme müssen nicht mal wissen, wer auf der anderen Seite sitzt. Der Broker macht die Arbeit.
In der Theorie steuern wir auf vollautomatische, KI-gestützte Cloud-Systeme zu, die selbstständig routen, skalieren und Fehler vorhersagen. Aber realistisch? Wir sind noch nicht ganz da. Entwickler lernen gerade erst, event-driven richtig zu verstehen und umzusetzen. Aber die Richtung stimmt – und Sofía ist überzeugt: Wir kommen da hin.
