Wie Teams Zielpfade als Regeln beschreiben — statt als Glue-Code

Warum Glue-Code so teuer wird

Jede neue Integration beginnt harmlos: ein kleiner Service, der ein Event entgegennimmt und weiterreicht. Nach dem dritten Empfänger hängt daran ein eigener Deploy-Zyklus, eine eigene Retry-Logik und ein eigener Bereitschaftsdienst.

Der Aufwand wächst nicht mit dem Volumen, sondern mit der Zahl der Verbindungen. Genau das macht Punkt-zu-Punkt-Integration auf Dauer unbezahlbar.

Was eine Regel beschreibt

Ein Zielpfad besteht aus drei Angaben: welche Events er annimmt, wie die Nutzdaten für das Ziel aussehen sollen und was bei einem Fehler passiert. Mehr braucht es nicht — und alles davon ist Konfiguration, kein Code.

Kurz gesagt:

„Ein Zielpfad ist eine Regel — kein Service, den jemand betreiben muss."

Was sich im Alltag ändert

Wenn Routing Konfiguration ist, verschiebt sich die Arbeit von der Auslieferung zur Beobachtung. Diese vier Punkte fallen Teams meist zuerst auf:

1. Ein neuer Empfänger ist eine Regel, kein Repository.
2. Änderungen greifen sofort — ohne Release-Fenster.
3. Retry und Replay verhalten sich überall gleich.
4. Der Zustand jedes Events ist an einer Stelle sichtbar.

Wo die Grenze liegt

Regeln ersetzen keine Fachlogik. Sobald ein Ziel mehr braucht als Filter und Mapping, gehört diese Logik in den Empfänger — der Pfad bleibt trotzdem beschreibbar.