Wie Sarahs Unternehmen mit Event-Driven Architecture (EDA) effizienter, schneller und anpassungsfähiger wurde

Sarah saß in ihrem Büro und starrte auf den Monitor. Es war wieder passiert. Eine einfache Bestellung auf der Website hatte dazu geführt, dass das gesamte System ins Stocken geraten war. Ihre Kunden waren frustriert, und das Feedback auf der Support-Seite lief über. Sarah war die leitende Entwicklerin in einem wachsenden E-Commerce-Unternehmen, und sie wusste, dass etwas Grundlegendes schieflief.

Die starren, monolithischen Systeme, mit denen ihr Unternehmen arbeitete, wurden immer wieder zur Bremse, wenn Bestellungen eingingen. Jeder Schritt musste nacheinander ausgeführt werden – die Bestellung wurde aufgegeben, die Zahlungsabwicklung begann, der Lagerbestand wurde überprüft, und schließlich wurde der Versand vorbereitet. Doch wenn ein Schritt nicht funktionierte, geriet das gesamte System ins Chaos. Sarah wusste, dass es so nicht weitergehen konnte. Sie brauchte eine neue Lösung, um die Effizienz zu steigern und ihre Systeme auf die nächste Stufe zu heben.

Die Entdeckung von Event-Driven Architecture

Eines Abends, als Sarah über mögliche Lösungen recherchierte, stieß sie auf das Konzept der Event-Driven Architecture (EDA). Die Idee klang vielversprechend: Anstatt, dass Systeme linear und sequenziell arbeiten, würden Ereignisse ausgelöst, auf die verschiedene Systeme parallel und autonom reagieren. Es war eine neue Denkweise, die mehr Flexibilität, Geschwindigkeit und Skalierbarkeit versprach.

Stell dir vor, du bist auf einem Konzert. Die Band spielt und jeder Musiker reagiert in Echtzeit auf die Musik. Der Schlagzeuger setzt einen Rhythmus, die Gitarre fügt sich ein, und die Sängerin passt ihren Gesang dynamisch an. Niemand wartet auf eine Anweisung – alle reagieren sofort auf das, was gerade passiert. In einer Event-Driven Architecture ist es ähnlich: Ein Ereignis, wie eine Bestellung oder eine Kundeninteraktion, wird ausgelöst und die verschiedenen Systeme des Unternehmens reagieren sofort und unabhängig darauf.

Sarah war fasziniert. Diese Architektur versprach nicht nur die Lösung ihrer aktuellen Probleme, sondern öffnete auch die Tür zu einer völlig neuen Art, wie Software entwickelt und betrieben werden konnte. Sie beschloss, es auszuprobieren.

Vom Monolithen zu autonom agierenden Systemen

Als Sarah das Konzept ihren Kollegen und ihrem Chef vorstellte, traf sie zunächst auf Widerstand. Der CTO des Unternehmens, Michael, war skeptisch. „Wir haben Jahre damit verbracht, unser aktuelles System zu entwickeln. Sollten wir wirklich alles über den Haufen werfen?“, fragte er. Aber Sarah ließ sich nicht entmutigen. Sie erklärte, dass der Wechsel zu EDA nicht bedeuten würde, das alte System komplett zu verwerfen. Vielmehr könnten sie schrittweise vorgehen und bestimmte Teile des Systems – wie die Bestellabwicklung – als erstes entkoppeln und als ereignisgesteuerte Services umsetzen.

Nach intensiven Diskussionen stimmte das Team zu, es zu versuchen. Sie begannen damit, einen einfachen Proof-of-Concept für die Zahlungsabwicklung zu erstellen, der auf Ereignissen basierte. Anstatt darauf zu warten, dass eine Bestellung vollständig verarbeitet war, um mit der Zahlungsabwicklung zu beginnen, wurde das Ereignis „Bestellung eingegangen“ direkt nach Abschluss der Bestellung ausgelöst. Sofort sprang der Zahlungsdienst an und begann die Bearbeitung – unabhängig davon, ob die Lagerabteilung bereits ihre Arbeit erledigt hatte.

Die ersten Erfolge: Schnellere Reaktionen, weniger Engpässe

Die Ergebnisse waren erstaunlich. Die Zeit, die benötigt wurde, um eine Bestellung zu verarbeiten, wurde drastisch reduziert. Während das alte System sequentiell arbeitete und auf den Abschluss jedes einzelnen Schrittes warten musste, konnten die ereignisbasierten Services parallel arbeiten. Dadurch konnten mehrere Schritte gleichzeitig ausgeführt werden, und das gesamte System lief reibungsloser und schneller.

Sarah und ihr Team waren begeistert. Doch während sie weiter an der Implementierung arbeiteten, stießen sie auf neue Herausforderungen.

Neue Hürden: Fehlerbehandlung und Konsistenz

Während Sarah und ihr Team ihre Event-Driven Architektur weiter ausbauten, stießen sie auf ein Problem, das sie anfangs nicht erwartet hatten: Konsistenz. Was passiert, wenn ein System ein Ereignis nicht korrekt verarbeitet? Was, wenn ein Ereignis von einem System anders interpretiert wird, als von einem anderen?

Sarah erinnerte sich an das Prinzip der Eventual Consistency, dass sie in ihrer Recherche entdeckt hatte. In einem ereignisbasierten System arbeiten viele Prozesse asynchron, was bedeutet, dass sie vorübergehend in verschiedenen Zuständen sein können. Doch mit der Zeit synchronisieren sie sich und erreichen einen konsistenten Zustand. Dieser Ansatz war eine große Umstellung für das Team, das gewohnt war, in starren, sequenziellen Prozessen zu denken. Aber Sarah erkannte, dass diese Flexibilität entscheidend war, um die Vorteile von EDA voll auszuschöpfen.

Um sicherzustellen, dass keine wichtigen Ereignisse verloren gingen, implementierten sie Retry-Mechanismen und Dead Letter Queues, um fehlgeschlagene Nachrichten aufzufangen und erneut zu verarbeiten. Damit konnte das Team gewährleisten, dass auch im Falle eines Fehlers keine Bestellung verloren ging und das System weiterhin robust blieb.

Die Transformation: EDA in Aktion

Nachdem das Team mehrere Monate an der Implementierung der Event-Driven Architecture gearbeitet hatte, war die Transformation vollständig. Bestellungen wurden nun in Echtzeit bearbeitet, und alle Systeme reagierten sofort und unabhängig voneinander auf Ereignisse. Das System war nicht nur schneller, sondern auch skalierbarer. Wenn das Unternehmen wuchs und mehr Bestellungen hereinkamen, konnte es problemlos mehr Ressourcen hinzufügen, ohne das Gesamtsystem zu belasten.

Für Sarah war dies der Höhepunkt ihrer Reise. Das System, das sie und ihr Team geschaffen hatten, war nicht nur effizienter, sondern auch zukunftssicher. Egal, welche neuen Anforderungen oder Technologien in den kommenden Jahren auf sie zukommen würden, das System war flexibel genug, um sich anzupassen.

EDA in der Praxis: Mehr als nur ein technisches Konzept

Sarahs Geschichte ist ein Beispiel dafür, wie Event-Driven Architecture nicht nur technische Probleme löst, sondern auch eine neue Denkweise in die Softwareentwicklung einführt. EDA ermöglicht es Unternehmen, schneller auf Veränderungen zu reagieren, Systeme flexibel zu gestalten und Engpässe zu vermeiden.

Ob im E-Commerce, bei Finanztransaktionen oder im IoT – Event-Driven Architecture zeigt, wie moderne Systeme auf Ereignisse reagieren und dadurch effizienter und skalierbarer werden können.

Beispiel: Event-Driven Architecture in Python

Zunächst erstellen wir ein einfaches Event-System. Hier werden verschiedene Event Producer (derjenige, der das Ereignis auslöst) und Event Consumer (die Systeme, die auf das Ereignis reagieren) simuliert.

Python Code:

import time
from threading import Thread

# Event-Broker (in einem echten System könnte das z. B. Kafka sein)


class EventBroker:
    def __init__(self):
        self.subscribers = {}

    # Füge neue Subscriber hinzu (die auf ein Ereignis warten)
    def subscribe(self, event_type, subscriber):
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(subscriber)

    # Veröffentliche ein Ereignis und benachrichtige alle Subscriber
    def publish(self, event_type, data):
        if event_type in self.subscribers:
            for subscriber in self.subscribers[event_type]:
                # Startet den Subscriber in einem separaten Thread
                Thread(target=subscriber, args=(data,)).start()

# Event Consumer: Zahlungssystem


def payment_service(order):
    print(f"Zahlung für Bestellung {order['order_id']} wird bearbeitet...")
    time.sleep(2)  # Simuliert Bearbeitungszeit
    print(f"Zahlung für Bestellung {order['order_id']} abgeschlossen.")

# Event Consumer: Lagerbestandsprüfung


def inventory_service(order):
    print(
        f"Lagerbestandsprüfung für Bestellung {order['order_id']} wird durchgeführt...")
    time.sleep(1)  # Simuliert Bearbeitungszeit
    if order['item_count'] > 0:
        print(f"Lagerbestände für Bestellung {order['order_id']} verfügbar.")
    else:
        print(
            f"Lagerbestände für Bestellung {order['order_id']} nicht verfügbar.")

# Event Producer: Bestellung aufgeben


def place_order(broker, order):
    print(f"Bestellung {order['order_id']} wurde aufgegeben.")
    broker.publish("order_placed", order)


# Hauptprogramm zur Simulation
if __name__ == "__main__":
    broker = EventBroker()

    # Subscriber (Zahlung und Lagerbestand) für das Ereignis "order_placed" registrieren
    broker.subscribe("order_placed", payment_service)
    broker.subscribe("order_placed", inventory_service)

    # Neue Bestellung aufgeben
    order = {"order_id": 123, "item_count": 5}

    # Ereignis "Bestellung aufgeben" wird ausgelöst
    place_order(broker, order)

Quellcode des Beispiels auf GitHub

Erklärung des Codes:

1. EventBroker: Der zentrale Broker, der die Ereignisse verwaltet. In einem echten System könnte dies ein System wie Apache Kafka oder RabbitMQ sein. Hier abonnieren verschiedene Services die Ereignisse, die sie interessieren. Im Beispiel habe ich dafür Threading in Python verwendet.
2. Event Consumers (Subscriber): Wir haben zwei Services:
   • payment_service: Simuliert die Zahlungsabwicklung für eine Bestellung.
   • inventory_service: Überprüft den Lagerbestand für die Bestellung.
3. Event Producer: Der place_order-Prozess simuliert das Aufgeben einer Bestellung. Wenn eine Bestellung aufgegeben wird, wird das Ereignis order_placed veröffentlicht, und die entsprechenden Services (Zahlung und Lager) werden benachrichtigt.
4. Asynchrone Verarbeitung: In einem echten Event-Driven System laufen solche Services oft asynchron, um die Reaktionszeit zu verbessern. Für den Anfang verwenden wir time.sleep, um die Verzögerung zu simulieren.

Ausgabe des Beispiels:

Bestellung 123 wurde aufgegeben.

Zahlung für Bestellung 123 wird bearbeitet...

Lagerbestandsprüfung für Bestellung 123 wird durchgeführt...

Lagerbestände für Bestellung 123 verfügbar.

Zahlung für Bestellung 123 abgeschlossen.

In diesem Beispiel wird klar, dass mehrere Services parallel auf das Ereignis “Bestellung aufgegeben” reagieren, ohne dass sie voneinander abhängen. Diese Architektur sorgt dafür, dass verschiedene Prozesse wie Zahlung und Lagerbestandsprüfung unabhängig voneinander und parallel ablaufen, was die Effizienz steigert und Engpässe reduziert.

Fazit: Sarahs Erfolgsstory als Wegweiser für die Zukunft

Sarahs Reise von einem starren Monolithen zu einer flexiblen Event-Driven Architecture zeigt, dass der Weg nicht immer einfach ist, aber die Belohnungen erheblich sein können. EDA bietet Unternehmen die Möglichkeit, auf Echtzeit-Ereignisse zu reagieren, Engpässe zu vermeiden und ein System aufzubauen, das auf die Anforderungen der Zukunft vorbereitet ist.

Wenn auch du vor der Herausforderung stehst, ein System zu entwerfen, das nicht nur den heutigen, sondern auch den zukünftigen Anforderungen gerecht wird, könnte die Event-Driven Architecture die Lösung sein. Lerne aus Sarahs Erfahrung und nutze die Kraft der Ereignisse, um deine Systeme zu transformieren.

Quellen

• “Building Event-Driven Microservices” von Adam Bellemare
  • Ein detailliertes Buch über die Implementierung von ereignisgesteuerten Systemen in Microservices. Es bietet praktische Beispiele und eine tiefgehende Erklärung zur Architektur.
  • Link zum Buch

Martin Fowler: “What is Event-Driven Architecture?”
Ein Artikel von einem der bekanntesten Softwarearchitekten, der erklärt, wie Event-Driven Architecture funktioniert und welche Vorteile sie bietet.

• Link zum Artikel

“The Principles of Event-Driven Architecture” von Confluent
Ein Leitfaden von Confluent, der EDA im Kontext von Kafka beschreibt und aufzeigt, wie verteilte Systeme durch EDA skalierbarer und effizienter werden können.

• Link zum Artikel

“Event-Driven Architecture Pattern” von Microsoft Azure
Microsoft bietet eine detaillierte Beschreibung, wie EDA in der Cloud implementiert werden kann, inklusive Anwendungsbeispiele und Best Practices.

• Link zur Azure Doku

“Reactive Systems vs. Event-Driven Architecture” von InfoQ
Dieser Artikel beleuchtet den Unterschied zwischen reaktiven Systemen und ereignisgesteuerten Architekturen, um Missverständnisse zu klären.

• Link zum Artikel

Weiter geht es mit einem Beispiel in Azure in meinem Artikel zu EDA mit Azure Functions und Azure Event Grid.