Event-Driven Architecture in der Produktion: Lektionen aus einer hochdurchsatzfähigen Order-Pipeline

Das Versprechen der Event-Driven Architecture

Event-Driven Architecture ist leicht zu verkaufen und schwer zu betreiben. Der Pitch ist verlockend: Entkopple deine Services, skaliere unabhängig, reagiere in Echtzeit auf Änderungen und baue Systeme, die lebendig erscheinen. Die Realität ist ein Stapel von Kompromissen rund um Ordering, Idempotenz, Observability, Schema-Evolution und Fehlermodi, über die die meisten Tutorials hinwegsehen.

Vor zwei Jahren hat mein Team einen monolithischen Order-Processor in eine event-gesteuerte Pipeline umgeschrieben. Das System verarbeitet heute mehrere Millionen Events pro Tag über Checkout, Zahlung, Lager, Fulfillment und Benachrichtigungen. Die Migration lehnte sich stark an die etablierten Muster aus Martin Fowlers Taxonomie der event-gesteuerten Architektur an sowie an die Betriebslektionen von Unternehmen wie LinkedIn, Uber, Netflix und Slack, die event-gesteuerte Plattformen im Internet-Maßstab betreiben. Dieser Artikel ist die Anleitung, die ich gerne gehabt hätte, bevor wir begonnen haben.

Warum wir Events gewählt haben

Das alte System war eine synchrone Kette von API-Aufrufen. Wenn ein Kunde eine Bestellung aufgegeben hat, rief der Web-Handler den Inventory-Service auf, der den Payment-Service rief, der den Fulfillment-Service rief, der den Notification-Service rief. Jeder Sprung fügte Latenz hinzu und vervielfachte den Ausbruchsradius eines Fehlers.

Wenn der Notification-Service langsam war, lief der Checkout in einen Timeout. Wenn der Inventory-Service unter Last geriet, schlugen Zahlungen fehl. Wenn Fulfillment ausfiel, wurde die gesamte Bestellung abgelehnt, obwohl die Zahlung bereits eingezogen war. Das System war so stark gekoppelt, dass Betriebsvorfälle vorhersehbar und die Wiederherstellung langsam waren.

Events lösten das Problem der direkten Kopplung. Der Web-Handler veröffentlicht ein OrderPlaced-Event und kehrt sofort zurück. Lager, Zahlung, Fulfillment und Benachrichtigungen verarbeiten das Event unabhängig. Wenn die Benachrichtigung langsam ist, kümmert sich der Checkout nicht darum. Wenn Fulfillment vorübergehend offline ist, können Bestellungen weiterhin angenommen und später verarbeitet werden.

Das war die Theorie. Die Praxis zwang uns, eine lange Liste von Fragen zu beantworten, die wir nicht vollständig bedacht hatten.

Die vier Muster der Event-Driven Architecture

Martin Fowler identifiziert vier unterschiedliche Muster, die Menschen oft unter dem Etikett "event-driven" zusammenfassen. Die Unterschiede zu verstehen ist entscheidend, denn jedes Muster löst ein anderes Problem und führt zu einer anderen Kostenstruktur.

Event Notification ist das leichteste Muster. Ein Service veröffentlicht eine kleine Nachricht, dass etwas passiert ist, und nachgelagerte Services reagieren. Das Event enthält in der Regel nur eine ID. Consumer, die mehr Informationen benötigen, müssen beim Produzenten nachfragen. Das hält die Payloads klein, erhält aber eine gewisse Kopplung, da die Consumer weiterhin wissen müssen, wie sie mit dem Produzenten sprechen.

Event-Carried State Transfer enthält genügend Daten im Event, damit Consumer ohne Rückfrage handeln können. Ein CustomerAddressChanged-Event trägt die neue Adresse. Ein OrderPlaced-Event trägt die Line Items. Das reduziert die Kopplung und verbessert die Widerstandsfähigkeit, da Consumer auch dann weiterarbeiten können, wenn der Produzent nicht verfügbar ist. Der Preis sind größere Payloads, replizierter Zustand und Eventual Consistency.

Event Sourcing macht das Event-Log zur alleinigen Wahrheitsquelle. Statt den aktuellen Zustand in einer Datenbank zu speichern und Events als Nebeneffekt zu veröffentlichen, hängen Sie Events an ein unveränderliches Log an und leiten den aktuellen Zustand durch Wiedergabe ab. Git ist das klassische Beispiel: der Arbeitsbaum wird aus dem Commit-Log abgeleitet. Event Sourcing bietet starke Audit-Trails, Zeitreihenabfragen und die Möglichkeit, Zustand neu aufzubauen, fügt aber erhebliche Komplexität um Schema-Evolution, externe Systemintegration und Snapshotting hinzu.

CQRS trennt das Modell zum Schreiben von dem Modell zum Lesen. Es geht nicht streng genommen um Events, passt aber natürlich zu Event Sourcing und Event-Carried State Transfer, da Events Lese-optimierte Projections speisen können. Das Schreibmodell verarbeitet Befehle und emittiert Events; das Lesemodell konsumiert Events und hält Projections für spezifische Abfragen vor.

Unsere Pipeline verwendet Event-Carried State Transfer für den Hauptlebenszyklus von Bestellungen, Event Notification für leichte Trigger und eine begrenzte Form von Event Sourcing für ein Audit-Log. Wir haben bewusst auf vollständiges CQRS für die meisten Services verzichtet, da Lese- und Schreibmodelle nicht unterschiedlich genug waren, um die Trennung zu rechtfertigen.

Event-Design ist die wichtigste Entscheidung

Der größte Fehler, den Teams machen, ist, Events als dünne Wrapper um Datenbankänderungen zu behandeln. Sie veröffentlichen OrderCreated-, OrderUpdated- und OrderDeleted-Events, die einer CRUD-Tabelle entsprechen. Das leakt internen Zustand und zwingt Consumer dazu, die Absicht aus einem Strom von Diffs zu rekonstruieren.

Wir lernten, Events um Geschäftsabsicht herum zu designen, nicht um Datenbankzeilen. Statt OrderUpdated verwenden wir OrderPlaced, PaymentConfirmed, InventoryReserved, OrderShipped und OrderCancelled. Jeder Event-Name beschreibt etwas, das im Geschäft passiert ist, nicht etwas, das in einer Tabelle geändert wurde.

Ein gut gestaltetes Event beantwortet drei Fragen:

1. Was ist passiert? Verwenden Sie ein Verb in der Vergangenheit im Event-Namen.
2. Worum ging es? Fügen Sie die Aggregat-ID und genügend Kontext hinzu, um das Thema zu verstehen.
3. Wozu? Fügen Sie die Daten hinzu, die der Consumer braucht, um zu handeln, ohne alles aufzunehmen, das Sie jemals brauchen könnten.

{
  "eventId": "evt_01J8XQ...",
  "eventType": "OrderPlaced",
  "aggregateId": "order_48291",
  "timestamp": "2026-06-10T14:23:11Z",
  "payload": {
    "orderId": "order_48291",
    "customerId": "cust_7721",
    "currency": "EUR",
    "total": 149.95,
    "lineItems": [
      { "sku": "SHOE-42-BLK", "quantity": 1, "unitPrice": 89.95 },
      { "sku": "SOCK-3PK", "quantity": 2, "unitPrice": 30.00 }
    ],
    "shippingAddress": {
      "country": "DE",
      "postalCode": "10115"
    }
  }
}

Beachten Sie, was nicht im Event enthalten ist. Es gibt keinen internen Datenbank-Primärschlüssel, keine Versionsfeld, keinen Status-Enum und keine Daten, die nur ein einziger Consumer benötigt. Das Event ist ein Vertrag, und jedes Feld darin ist eine Zusage.

Choreografie versus Orchestrierung

Sobald Sie Events haben, müssen Sie entscheiden, wer den Workflow koordiniert. Es gibt zwei große Ansätze.

Choreografie bedeutet, dass jeder Service unabhängig auf Events reagiert und neue Events emittiert, wenn er fertig ist. Es gibt keinen zentralen Koordinator. Der Order-Service emittiert OrderPlaced; Inventory konsumiert es und emittiert InventoryReserved; Payment konsumiert OrderPlaced und emittiert PaymentConfirmed; Fulfillment wartet auf sowohl InventoryReserved als auch PaymentConfirmed, bevor es versendet. Das ist sehr entkoppelt und skaliert gut, aber der globale Workflow ist implizit. Sie können nicht einen Codeabschnitt lesen und den gesamten Prozess sehen.

Orchestrierung führt einen zentralen Koordinator ein, oft als Workflow-Engine oder Saga-Orchestrierer bezeichnet, der die Schritte explizit sequenziert. Der Orchestrierer sendet Befehle an Services und wartet auf Antworten. Das macht den Workflow sichtbar und leichter verständlich, führt aber eine zentrale Abhängigkeit wieder ein und kann zum Engpass werden.

Wir verwenden Choreografie für den Standard-Bestellfluss, da die Schritte gut verstanden und die Services stabil sind. Wir verwenden Orchestrierung für komplexe Rückerstattungs- und Austausch-Workflows, da diese Verzweigungslogik, Kompensationsaktionen und Timeouts erfordern, die sich schwer als reine Choreografie ausdrücken lassen. Viele Produktionssysteme, einschließlich derer von Uber und Netflix, verwenden letztendlich beides.

Ordering und Partitionierung sind nicht optional

Eine der ersten Überraschungen war, dass Event-Consumer Events nicht automatisch in der Reihenfolge verarbeiten, die ein Mensch erwarten würde. Wenn ein Kunde eine Bestellung aufgibt und sofort storniert, kann das OrderCancelled-Event in einer anderen Partition oder Consumer-Gruppe vor dem OrderPlaced-Event ankommen.

Wir mussten entscheiden, welche Ordering-Garantien wir tatsächlich brauchten. Für Zahlung und Lager ist die Reihenfolge extrem wichtig. Eine Stornierung darf nicht vor der ursprünglichen Platzierung verarbeitet werden. Für Benachrichtigungen ist die Reihenfolge weniger wichtig. Eine Versandbestätigung vor einer Zahlungsbestätigung ist verwirrend, aber nicht katastrophal.

Unsere Lösung war die Partitionierung von Events nach Aggregat-ID. Jedes Event, das zur selben Bestellung gehört, landet in derselben Partition, was die Reihenfolge innerhalb des Streams dieser Bestellung garantiert. Consumer, die strikte Reihenfolge benötigen, abonnieren diese Partitionen. Consumer, die keine strikte Reihenfolge benötigen, können Events aus jeder Partition parallel verarbeiten.

function partitionKeyFor(event: OrderEvent): string {
  if (event.aggregateId.startsWith('order_')) {
    return event.aggregateId;
  }
  return event.eventType;
}

Das ist nicht kostenlos. Die Partitionierung nach Bestellung bedeutet, dass eine einzelne heiße Bestellung nicht parallelisiert werden kann. Während Flash-Sales können wenige SKUs Partition-Hotspots erzeugen und die gesamte Pipeline verlangsamen. Wir mildern das ab, indem wir Reservierungs-Events von allgemeinen Bestelllebenszyklus-Events trennen, damit die Lagerreservierung unabhängig skalieren kann.

Das Rebalancing von Consumer-Gruppen ist eine weitere Ordering-Falle. Wenn ein Consumer einer Gruppe beitritt oder sie verlässt, werden Partitionen neu zugewiesen. Wenn ein Consumer bereits einige Events einer Partition verarbeitet, aber den Offset noch nicht committed hat, kann der neu zugewiesene Consumer diese Events erneut verarbeiten. Deshalb sind Idempotenz und At-Least-Once-Semantik nicht verhandelbar.

Idempotenz bewahrt Ihren Verstand

Events werden mindestens einmal zugestellt. Netzwerkstöße, Consumer-Neustarts und Retries erzeugen alle Duplikate. Wenn Ihr Consumer nicht idempotent ist, versenden Sie dieselbe Bestellung zweimal, belasten dieselbe Karte zweimal oder reservieren denselben Lagerbestand zweimal.

Jeder Consumer muss von Natur aus idempotent sein. Das einfachste Muster ist, verarbeitete Event-IDs in einem Deduplication-Store mit einer TTL zu verfolgen, die Ihrem Retention-Fenster entspricht. Ein robusteres Muster macht die nachgelagerte Operation selbst idempotent.

Unser Payment-Processor akzeptiert beispielsweise einen idempotencyKey für jede Charge-Anfrage. Wir verwenden die Event-ID als Schlüssel. Wenn dasselbe PaymentConfirmed-Event zweimal verarbeitet wird, gibt der zweite Aufruf die zuvor erstellte Charge zurück, anstatt eine neue zu erstellen.

async function handlePaymentConfirmed(event: PaymentConfirmedEvent): Promise<void> {
  const charge = await payments.charge({
    amount: event.payload.amount,
    currency: event.payload.currency,
    source: event.payload.paymentMethod,
    idempotencyKey: event.eventId,
  });

  await orderProjection.update(event.aggregateId, {
    paymentStatus: 'confirmed',
    chargeId: charge.id,
    paidAt: charge.createdAt,
  });
}

Der Idempotenzschlüssel ist kein Komfort. Er ist der Vertrag, der den Event-Consumer bei Retries sicher macht. Ohne ihn bauen Sie ein System, das meistens funktioniert und unter Last katastrophal versagt.

Exactly-Once-Semantik: sinnvoll oder Overkill?

Ein wachsender Trend in event-gesteuerten Systemen ist der Drang zu Exactly-Once-Verarbeitungssemantik. Kafka unterstützt idempotente Produzenten und Transaktionen. Flink und Kafka Streams bieten Exactly-Once-Garantien für Stream Processing. Für Finanz-, Gesundheits- und E-Commerce-Systeme kann Exactly-Once den Bedarf an manueller Abstimmung eliminieren.

Wir haben Exactly-Once für die Zahlungsverarbeitung in Betracht gezogen, aber letztendlich bei At-Least-Once plus idempotenten Consumern geblieben. Der Grund war betriebliche Einfachheit. Exactly-Once-Semantik erfordert transaktionale Produzenten, sorgfältige Consumer-Konfiguration und ein tiefes Verständnis dafür, wie Commits mit Nebeneffekten interagieren. In unserem Maßstab und mit unserer Teamgröße waren idempotente Consumer plus klare Metriken leichter zu verstehen und zu debuggen.

Die Entscheidung hängt von Ihrer Toleranz gegenüber Duplikaten und der betrieblichen Reife Ihres Teams ab. Wenn ein dupliziertes Event ein regulatorisches oder finanzielles Problem verursachen würde, das nicht durch Idempotenz behoben werden kann, ist Exactly-Once die Komplexität wert. Andernfalls ist At-Least-Once mit idempotenten Operationen normalerweise die pragmatische Wahl.

Fehlerbehandlung und Dead Letter Queues

In einem synchronen System gibt ein fehlgeschlagener Aufruf in der Regel einen Fehler an den Aufrufer zurück. In einem event-gesteuerten System hat ein fehlgeschlagener Consumer keinen Aufrufer. Das Event bleibt liegen, wird erneut versucht, blockiert die Partition und vergiftet möglicherweise nachgelagerte Consumer.

Wir haben eine mehrstufige Fehlerbehandlungsstrategie implementiert:

1. Vorübergehende Fehler werden mit exponentiellem Backoff und Jitter erneut versucht. Netzwerk-Timeouts, Datenbankkontention und Drittanbieter-Rate-Limits fallen in diese Kategorie.
2. Verletzungen von Geschäftsregeln werden in eine Quarantäne-Warteschlange zur manuellen Prüfung gestellt. Das sind keine Bugs; es sind Fälle, die der Code explizit nicht behandeln kann.
3. Dauerhafte Fehler gehen nach wenigen Retries in eine Dead Letter Queue. Ein Alarm wird ausgelöst und ein Ingenieur untersucht das Problem.

Die Anzahl der Retries und die Backoff-Strategie hängen vom Consumer ab. Die Zahlungsverarbeitung versucht dreimal innerhalb von dreißig Sekunden erneut, da ein Kartennetzwerk kurzzeitig ausfallen kann. Die Lagerreservierung versucht aggressiver erneut, da das Verkaufsfenster kurz ist. Die Benachrichtigungszustellung versucht über Stunden erneut, da ein vorübergehender Ausfall eines Providers das Event nicht verlieren sollte.

Entscheidend ist, dass Retries die Reihenfolge nicht zerstören dürfen. Wenn ein Consumer bei Event N fehlschlägt und weiter versucht, ist Event N+1 in derselben Partition blockiert. Wir verwenden ein Retry-Topic mit einer Verzögerungsmechanik, damit fehlgeschlagene Events wiedereingereiht werden, während die Partition weiterläuft.

Backpressure und Flow Control

Nicht jeder Consumer kann mit dem Produzenten Schritt halten. Während einer Marketing-Kampagne kann der Checkout-Service zehntausend Events pro Sekunde veröffentlichen, während der Analytics-Consumer nur zweitausend pro Sekunde verarbeiten kann. Ohne Backpressure fällt der Analytics-Consumer zurück, der Speicher wächst und der Prozess stürzt schließlich ab.

Die erste Verteidigung ist Skalierung. Wir betreiben mehrere Consumer-Instanzen pro Consumer-Gruppe, begrenzt durch die Anzahl der Partitionen. Wenn wir mehr Durchsatz brauchen, erhöhen wir die Anzahl der Partitionen, was Planung erfordert, da das Repartitionieren eines Topics in der Produktion störend ist.

Die zweite Verteidigung ist Flow Control. Einige Consumer können unkritische Events während einer Überlastung überspringen. Unser Analytics-Consumer kann beispielsweise Hochfrequenz-Events stichprobenartig auswählen, wenn der Lag einen Schwellenwert überschreitet. Die Kerngeschäftsverarbeitung kann nicht stichprobenartig auswählen, also skaliert sie stattdessen aus.

Die dritte Verteidigung ist Circuit Breaking. Wenn eine nachgelagerte Abhängigkeit wie der Payment-Processor ausfällt, hören wir auf, sie zu bombardieren, und lassen das Retry-Topic die Events puffern. Das schützt die Abhängigkeit und verhindert, dass der Consumer CPU für Anfragen verbrennt, die zwangsläufig fehlschlagen.

Observability verändert alles

Das Debuggen von event-gesteuerten Systemen ist schwieriger als das Debuggen synchroner Systeme. Sie können einer einzelnen Anfrage nicht durch einen Call-Stack folgen. Sie müssen eine Geschichte aus verstreuten Logs, Metriken und Traces rekonstruieren.

Wir haben drei Schichten der Observability aufgebaut:

• Distributed Tracing mit einer Korrelations-ID, die sich vom ursprünglichen HTTP-Request durch jedes produzierte und konsumierte Event ausbreitet. Eine einzelne Trace zeigt den gesamten Lebenszyklus einer Bestellung.
• Event-Metriken einschließlich Publish-Rate, Consume-Rate, Lag pro Partition, Retry-Rate und Dead-Letter-Rate. Das sind die Vitalzeichen der Pipeline.
• Audit-Log jedes veröffentlichten und konsumierten Events, gespeichert in einem Object Store mit langem Aufbewahrungsfenster. Das ist unschätzbar für Vorfalluntersuchungen und Compliance.

Die Metrik, die uns am häufigsten gerettet hat, war der Consumer Lag. Ein plötzlicher Anstieg des Lags zeigt an, dass ein Consumer zurückfällt, bevor er vollständig ausfällt. Wir alarmieren auf Perzentil-Schwellen des Lags, nicht nur auf Fehler.

Unser Standard-Vorfall-Runbook beginnt mit drei Fragen: Veröffentlicht der Produzent? Hält der Consumer mit? Wächst die Dead Letter Queue? Diese drei Metriken sagen uns normalerweise, welcher Teil der Pipeline krank ist.

Serialisierung und Schema-Evolution

Events leben länger als Services. Ein Jahr nach der Veröffentlichung eines Events können drei neue Teams es konsumieren und zwei ursprüngliche Produzenten seine Form geändert haben. Wenn Sie Event-Schemas als Nachgedanken behandeln, schaffen Sie ein Minenfeld impliziter Abhängigkeiten.

Wir begannen mit JSON für Lesbarkeit und Debuggability, wechselten dann aber zu Avro für leistungskritische Topics. Eine Confluent-Studie ergab, dass der Wechsel von JSON zu Avro die Payload-Größe um etwa siebzig Prozent reduzieren und die Latenz in Hochfrequenzumgebungen um einige zehn Millisekunden pro Event senken kann. Für eine Pipeline, die Millionen von Events pro Tag verarbeitet, macht das einen Unterschied.

Wir verwenden eine Schema Registry mit Forward- und Backward-Kompatibilitätsprüfungen. Jedes Event hat ein versioniertes Schema. Produzenten validieren Events vor der Veröffentlichung gegen das Schema. Consumer deklarieren, welche Schema-Versionen sie unterstützen.

Die Regel, die wir durchsetzen, ist einfach: Nur additive Änderungen, es sei denn, jeder Consumer wurde migriert. Sie können optionale Felder hinzufügen. Sie können keine Felder entfernen oder den Typ bestehender Felder ohne einen formalen Deprecation-Zyklus ändern.

# schemas/order-placed/v1.yaml
name: OrderPlaced
version: 1
type: record
fields:
  - name: orderId
    type: string
  - name: customerId
    type: string
  - name: total
    type: decimal
    scale: 2
  - name: lineItems
    type: array
    items:
      type: record
      fields:
        - name: sku
          type: string
        - name: quantity
          type: int
        - name: unitPrice
          type: decimal
          scale: 2

Als wir ein Feld giftMessage hinzufügen mussten, erstellten wir eine v2 mit dem neuen optionalen Feld, aktualisierten Produzenten auf v2 und gaben den Consumern zwei Sprints Zeit zur Migration. Da das Feld optional war, konnten alte Consumer v2-Events ohne Änderungen lesen. Diese Disziplin wirkt bürokratisch, bis Ihr erster Breaking Change kommt. Dann wirkt sie wie der einzige Grund, warum das System noch läuft.

Wann Event-Driven die falsche Wahl ist

Event-Driven Architecture ist kein universelles Upgrade. Wir haben gelernt, sie in drei Situationen zu vermeiden.

Erstens, wenn starke Konsistenz erforderlich ist und das Geschäft Eventual Consistency nicht tolerieren kann. Wenn eine Aktion sofort in jedem Read Model reflektiert werden muss, ist synchrone Koordination oft einfacher und sicherer.

Zweitens, wenn der Workflow grundsätzlich sequentiell ist und jeder Schritt vor dem nächsten abgeschlossen sein muss. Das in Events zu zwingen fügt Komplexität hinzu, ohne etwas Bedeutendes zu entkoppeln.

Drittens, wenn das Team nicht die betriebliche Reife hat, um verteilte Systeme zu betreiben. Event-gesteuerte Systeme scheitern auf subtile Weise. Wenn Sie keine gute Observability, Runbooks und eine Bereitschaftsrotation haben, verbringen Sie mehr Zeit damit, gegen die Architektur zu kämpfen, als von ihr zu profitieren.

Was wir anders machen würden

Wenn wir von vorne beginnen würden, würden wir den Event-Katalog schreiben, bevor wir einen einzigen Consumer schreiben. Wir schrieben zuerst den Code und benannten dann die Events, was zu einem inkonsistenten Vokabular über die Services führte. Events umzubenennen ist schmerzhaft, da Consumer von den Namen abhängen.

Wir würden auch früher in Alarme für Consumer Lag investieren. Als ein Consumer während eines Verkaufs zum ersten Mal zurückfiel, entdeckten wir das Problem durch Kundenbeschwerden, nicht durch Metriken. Lag-Alerting ist heute eines unserer wichtigsten operativen Signale.

Schließlich würden wir von Tag eins eine Schema Registry verwenden. Die nachträgliche Anpassung der Schema-Validierung an einen Event-Stream in der Produktion bedeutete, Deployments über Teams zu koordinieren und vorübergehende Risiken zu akzeptieren, die hätten vermieden werden können. Wir hätten Avro für Hochdurchsatz-Topics auch früher gewählt, anstatt JSON-Overhead mit sich herumzuschleppen, bis der Lag sichtbar wurde.

Takeaways

Event-Driven Architecture ist ein leistungsstarkes Werkzeug zur Entkopplung und Skalierung, aber sie verschiebt Komplexität vom Call Graph zum Betriebsmodell. Verstehen Sie, welches Muster Sie verwenden: Notification, Event-Carried State Transfer, Event Sourcing oder CQRS. Designen Sie Events um Geschäftsabsicht, nicht Datenbankzeilen. Wählen Sie Choreografie oder Orchestrierung basierend auf der Workflow-Komplexität. Erzwingen Sie Ordering nur dort, wo es wirklich nötig ist. Machen Sie jeden Consumer idempotent. Behandeln Sie Retries, Dead Letter Queues, Backpressure und Observability als Erstklass-Anliegen. Regieren Sie Schemas formal. Und seien Sie ehrlich darüber, ob Ihr Problem wirklich Events braucht oder ob ein einfacheres synchrones Design Sie nicht besser bedient.

Das Ziel ist nicht, mehr Events zu verwenden. Das Ziel ist es, Systeme zu bauen, die seltener ausfallen, schneller wiederhergestellt werden und mit zunehmender Größe verständlich bleiben.

Verfasst von

Miracle Kalu

Senior Full Stack Engineer

Veröffentlicht 13. Juni 2026 · 14 Min. Lesezeit