Eine Anfrage stellt eine Frage und wartet auf die Antwort. Ein Event meldet einen Fakt und geht weiter.
Fast jede Integrationsentscheidung lässt sich auf diesen Satz zurückführen — und fast jede schwer zu betreibende Landschaft ist das Ergebnis davon, ihn zu ignorieren. Die Muster sind keine Rivalen; sie beantworten unterschiedliche Fragen. Der Schmerz beginnt, wenn eines in die Rolle des anderen gezwungen wird.
Das Muster ist keine technische Vorliebe. Es ist ein Versprechen darüber, wie zwei Systeme gemeinsam ausfallen werden.
Wählen Sie Request-Response, wenn der Aufrufer ohne die Antwort nicht weiterkommt. Wählen Sie ein Event, wenn der Fakt für mehr Konsumenten zählt, als Sie heute benennen können.
Was jedes Muster tatsächlich verspricht
Ein synchroner Aufruf koppelt die Verfügbarkeit
Wenn System A System B aufruft und wartet, hat A stillschweigend dessen Verfügbarkeit, Latenz und Wartungsfenster geerbt. Einen Aufruf tief ist das unproblematisch. Drei Sprünge tief bestimmt das schwächste System der Kette die Verfügbarkeit der gesamten Strecke — und niemand hat dem zugestimmt.
Ein Event entkoppelt die Zeit
Der Producer meldet “Mitarbeiter eingestellt”, “Auftrag angelegt”, “Buchung freigegeben” — und ist fertig. Konsumenten verarbeiten in ihrem eigenen Tempo, lassen sich ohne Eingriff beim Producer ergänzen und können nach einer Störung erneut abspielen. Der Preis: niemand wartet, also weiß niemand sofort, ob es nachgelagert geklappt hat.
Beim Scheitern unterscheiden sich die Muster wirklich
Ein fehlgeschlagener Aufruf scheitert laut, direkt vor dem Aufrufer, im Moment der Anfrage — ideal, wenn ein Mensch auf die Antwort wartet. Ein fehlgeschlagenes Event scheitert leise, später, in einer Queue — ideal, wenn die Zustellung eine Störung überleben muss, und gefährlich, wenn niemand das Monitoring dieser Queue verantwortet.
Die Entscheidung entlang der Dimensionen, die sie bestimmen
SAP Integration Suite trägt beide Muster — Cloud-Integration-Flows und verwaltete APIs auf der einen Seite, die Event-Mesh-Funktionen auf der anderen — sodass die Wahl pro Schnittstelle statt pro Plattform getroffen werden kann.
Die Landschaft braucht beides — und zwar bewusst
Reale Landschaften sind gemischt: Wer die Bankverbindung eines Mitarbeitenden prüft, braucht eine synchrone Antwort; die Einstellung, die diesen Mitarbeitenden angelegt hat, hätte ein Event sein sollen — denn Entgeltabrechnung, IT-Provisionierung, Berechtigungsverwaltung und Analytics interessieren sich alle dafür, und keines davon sollte die Einstellungstransaktion aufhalten.
Der Warnhinweis ist Gleichförmigkeit. Eine Landschaft, in der alles ein Punkt-zu-Punkt-API-Aufruf ist, hat meist genau den Wildwuchs neu erschaffen, den sie ablösen sollte — mit besserem Logging. Eine Landschaft, in der alles ein Event ist, hat meist festgestellt, dass manche Fragen doch Antworten brauchten.
Die Interaktion benennen→Frage oder Fakt?→Den Vertrag wählen→Zuerst den Fehlerpfad entwerfen
Regeln, die den Kontakt mit der Produktion überstehen
- Entscheiden Sie pro Interaktion, nicht pro Projekt. Ein einzelner Prozess enthält meist sowohl eine Frage als auch mehrere Fakten.
- Machen Sie jeden Konsumenten idempotent. Wiederholungen und Replays sind ein Merkmal robuster Integration, keine Anomalie — dieselbe Nachricht zweimal zu verarbeiten muss sicher sein.
- Geben Sie jeder Queue einen Verantwortlichen. Eine unüberwachte Dead-Letter-Queue ist eine Störung mit Zeitverzögerung.
- Versionieren Sie den Vertrag, nicht die Konsumentenliste. Der Sinn eines Events ist, dass der Konsument von morgen den Producer nichts kostet.
Perspektive von VISCAP
Integrationsschulden sind Verfügbarkeitsschulden. Jeder synchrone Sprung, den Sie heute hinzufügen, ist eine Störung, die Sie für später mitunterschreiben.
Wenn wir eine Landschaft prüfen, lesen wir die Schnittstellenliste gegen eine Frage: Wer wartet auf wen, und hat das jemand bewusst entschieden? Die Karte des unbeabsichtigten Wartens — Batch-Jobs, die auf Live-Aufrufe blockieren, Oberflächen, die auf Service-Ketten blockieren — ist meist der schnellste Weg zu Stabilität und Tempo zugleich.
Die Frage, die Sie jeder neuen Schnittstelle stellen sollten
Nicht zuerst “API oder Event?” — sondern “Wenn die Gegenseite eine Stunde lang ausfällt, was soll hier passieren?” Beantworten Sie das ehrlich, und das Muster wählt sich meist von selbst.