Organisationen mit Dutzenden von Systemen stehen meist vor einem Gewirr aus Punkt-zu-Punkt-Verbindungen: Jedes System kommuniziert direkt mit mehreren anderen, jeweils mit eigenem Protokoll und eigenem Vertrag. Die Folge: Die Änderung eines Systems legt mehrere andere lahm, und das Hinzufügen eines neuen Kanals, etwa einer mobilen App, erfordert monatelange Integrationsarbeit. Will ein Team wissen, was die letzte Transaktion eines Kunden war, muss es drei Systeme abfragen und die Antworten von Hand zusammenführen. Die Integrationsschicht ist faktisch unsichtbar über alle Systeme verteilt und gehört niemandem.
Das ist wichtig, weil das Tempo der digitalen Transformation einer Organisation unmittelbar an das Tempo ihrer Integration gekoppelt ist. Erfordert jedes neue Produkt eine erneute Anbindung an die zentralen Systeme, werden die Kosten für das Erproben neuer Ideen untragbar. Zudem ist jede direkte Verbindung ein unbeaufsichtigter Sicherheitspunkt: Wer ruft auf, mit welcher Berechtigung, mit welcher Rate? Ohne gemeinsame Schicht werden diese Fragen für jede Verbindung einzeln beantwortet, was in der Praxis bedeutet, dass niemand die vollständige Antwort kennt.
Die bevorzugte Architektur stellt zwei sich ergänzende Muster nebeneinander. Das API-Gateway ist der zentrale Einstiegspunkt für synchrone Interaktionen: Ein Konsument sendet eine Anfrage und erhält im selben Moment eine Antwort. Das Gateway wendet Authentifizierung, Autorisierung, Rate Limiting, Versionierung und Observability einheitlich an. Die ereignisgesteuerte Architektur dient asynchronen Interaktionen: Geschieht etwas, etwa eine Kontoeröffnung oder eine Adressänderung, veröffentlicht das Quellsystem ein Event, und jedes interessierte System konsumiert es, ohne dass die Quelle wissen muss, wer die Konsumenten sind. Eine dauerhafte Message Queue dazwischen garantiert, dass kein Event verloren geht.
Die erste praktische Überlegung betrifft das Vertragsdesign. APIs und Events sind beide Verträge und sollten auch so behandelt werden: mit explizitem Schema, expliziter Versionierung und einer klaren Regel für kompatible gegenüber inkompatiblen Änderungen. So ist etwa das Hinzufügen eines optionalen Feldes zu einem Event „Kunde aktualisiert“ eine kompatible Änderung, während die Änderung des Typs eines bestehenden Feldes eine neue Version erfordert, die für eine Übergangszeit parallel zur alten veröffentlicht wird. Eine zentrale Schema Registry ermöglicht es Teams, die Kompatibilität vor der Bereitstellung automatisch zu prüfen, statt einen Bruch erst im Produktivbetrieb zu entdecken.
Die zweite Überlegung betrifft die richtige Wahl zwischen synchron und asynchron. Die Faustregel: Braucht der Konsument die Antwort sofort, um seine eigene Arbeit fortzusetzen, verwenden Sie eine API; muss er nur wissen, dass etwas geschehen ist, verwenden Sie ein Event. Eine Saldoabfrage ist synchron. Die Benachrichtigung des Systems zur Geldwäschebekämpfung über eine Transaktion ist asynchron. Viele Leistungs- und Kopplungsprobleme in Organisationen rühren daher, dass asynchrone Interaktionen als synchrone Aufrufe umgesetzt sind, sodass ein langsames System die gesamte Kette verlangsamt.
Die dritte Überlegung betrifft durchgängige Observability. Wenn eine Anfrage über das Gateway eintrifft, mehrere Services durchläuft und mehrere Events erzeugt, muss das Team den gesamten Pfad mit einer einzigen Korrelations-ID verfolgen können. Diese ID muss sowohl in den API-Headern als auch in den Event-Metadaten mitgeführt werden. Ohne sie wird die Fehlersuche zum manuellen Abgleich von Zeitstempeln in den Logs mehrerer Systeme, was zu Spitzenzeiten praktisch unmöglich ist.
Die typischen Fallstricke lassen sich in einige Gruppen einteilen. Erstens: das API-Gateway zum Sitz von Geschäftslogik zu machen; das Gateway soll Richtlinien durchsetzen, keine Geschäftsentscheidungen treffen. Zweitens: „fette“ Events, die den gesamten Datensatz transportieren und Konsumenten an die interne Struktur der Quelle binden, oder „dünne“ Events, die nur eine Kennung enthalten und alle zu Rückfragen zwingen. Drittens: Reihenfolge und Duplikate zu ignorieren; ein Konsument muss ein wiederholtes Event erkennen und eines verarbeiten können, das außer der Reihe eintrifft. Viertens: keinen Verantwortlichen für die Integrationsschicht zu haben, wodurch sie still in den vorherigen Zustand zurückfällt.
Bei Niadad ist diese Triade als drei sich ergänzende Plattformen umgesetzt. Sepehr ist das Enterprise-API-Gateway: Authentifizierung, Autorisierung, Rate Limiting, Versionierung und Observability für alle synchronen Interaktionen. Jarian ist die Event-Plattform: Veröffentlichung, Abonnement und Event-Schemata mit gespeicherter Historie. Payam ist die dauerhafte Message Queue, die garantierte Zustellung und Fehlerbehandlung für asynchrone Verarbeitung bietet. Im Banking-Programm von Niadad bilden diese drei das Integrationsrückgrat und sind mit den Identitäts-, Partner- und Datenschichten verbunden.
Ein API-Gateway und eine ereignisgesteuerte Architektur sind zwei Antworten auf zwei unterschiedliche Fragen, und eine reife Organisation verfügt über beide. Was sie zu einer Infrastruktur macht, sind explizite Verträge, gemeinsame Identität und durchgängige Observability. Sind diese drei vorhanden, wird das Hinzufügen eines neuen Kanals oder Systems von einem mehrmonatigen Projekt zu einer Sache von Tagen. Das ist der eigentliche Maßstab einer Integrationsschicht: nicht, wie elegant ihr Diagramm aussieht, sondern wie wenig sie der nächsten Änderung im Weg steht.