Enterprise-Integration: 5 Dinge, die in der Produktion kaputtgehen

Die meisten Enterprise-Integrationen funktionieren für 95 % des Traffics einwandfrei. Die 5 %, die kaputtgehen — die nächtliche ERP-Synchronisation, die Rechnungen dupliziert, das Payment-Gateway, das elf Minuten lang nicht antwortet, die Versand-API, die einen 200er mit einem Error-Body zurückgibt — fressen den Großteil der operativen Kosten auf.

Nach einem Jahrzehnt Bauen von ERP-, E-Commerce-, Payment- und Datenintegrationen für tschechische und europäische Kunden tauchen fünf Fehlermodi immer und immer wieder auf. Jeder hat einen unspektakulären Fix, den 95 % der Integrationen nicht umsetzen.

1. Keine Idempotenz auf der Consumer-Seite

Der Klassiker: Ihr System postet eine Bestellung an ein ERP, das ERP akzeptiert sie und antwortet, dann hat das Netzwerk einen Aussetzer und Ihr Client-seitiger Retry löst eine doppelte Übermittlung aus. Glückwunsch — Sie haben gerade dieselbe Bestellung zweimal verschickt.

Der Fix ist ein Idempotency Key. Generieren Sie einen stabilen, eindeutigen Identifier auf der Producer-Seite (oft eine UUID, die an das Quell-Event gebunden ist), geben Sie ihn in jedem Request mit und verpflichten Sie den Consumer, ihn mindestens einen Tag lang zu merken. Kommt derselbe Key zweimal an, gibt der Consumer beide Male dieselbe Antwort zurück.

Producer: Generieren Sie den Key immer vor dem ersten Versuch, nicht erst beim Retry. Consumer: Persistieren Sie den Key zusammen mit dem Ergebnis — nicht nur „wir haben diesen Key gesehen“, sondern „wir haben diesen Key gesehen und das Ergebnis war X“. Der Retry muss dasselbe Ergebnis zurückbekommen.

2. Synchrone Aufrufe über Trust Boundaries hinweg

Wenn Sie ein externes Payment-Gateway synchron aus Ihrem Checkout-Endpoint aufrufen, haben Sie Ihre Checkout-Latenz an die Infrastruktur eines anderen gebunden. Dessen schlechter Nachmittag ist jetzt Ihr schlechter Nachmittag. Schlimmer: Wenn dessen Timeout länger ist als das Ihres Load Balancers, bekommen Sie halb abgeschlossene Transaktionen ohne deterministischen Recovery-Pfad.

Der Fix ist das Standard-„Outbox Pattern“:

1. Ihr Checkout-Endpoint schreibt die ausstehende Bestellung in Ihre eigene Datenbank — und schreibt in derselben Transaktion eine Zeile in eine Outbox-Tabelle mit dem Inhalt „das an das Payment-Gateway posten“.
2. Ein separater Worker-Prozess (gleiche Codebase, anderes Deployment) liest aus der Outbox, ruft das Gateway auf und schreibt das Ergebnis zurück.
3. Ihr Checkout-Endpoint kehrt sofort mit einem Status „wird bearbeitet, wir schicken eine E-Mail“ zurück. Die UI pollt oder bekommt einen Webhook.

Der Load Balancer sieht den externen Aufruf nie. Ihr Checkout bleibt unter 200 ms. Der Worker hat eigene Timeout- und Retry-Logik, die Sie unabhängig tunen können. Und wenn das Gateway einen schlechten Nachmittag hat, sehen Sie einfach einen Backlog, der sich in Minuten abbaut, sobald sie wieder da sind.

3. Stiller Schema-Drift

Ihre ERP-Integration übergibt ein JSON-Payload mit den Feldern orderId, customerId, total. Sechs Monate später fügt jemand im ERP-Team taxCode hinzu. Ihr Code nutzt es nicht, also merken Sie nichts. Ein Jahr später hängt eine Geschäftsregel von taxCode ab — außer in Ihrem System, weil Ihre Integration nie davon erfahren hat.

Der Fix ist ein maschinenlesbarer Vertrag und ein CI-Gate. Speichern Sie das Schema jedes Integrations-Payloads im Repo (JSON Schema, Zod, Pydantic — was auch immer zum Stack passt). Validieren Sie an der Grenze. Wenn der Producer ein neues Feld schickt, von dem Sie nichts wissen, akzeptieren Sie es entweder explizit (Allow-Listing) oder loggen Sie eine Warnung — niemals stillschweigend ignorieren.

Noch wichtiger: Wenn SIE ein Schema ändern, sollte die CI den PR ablehnen, wenn die Consumer-Tests auf der anderen Seite der Grenze nicht durchlaufen. Verträge sind nutzlos, wenn jede Seite sie unabhängig aktualisiert.

4. Timeouts ohne Budgets

Ein verteilter Aufruf hat drei Timeouts, die zählen: der TCP-Level-Socket-Timeout, der Application-Level-Read-Timeout und die SLO-Deadline des Aufrufers. Die meisten Codebases setzen nur einen davon. Die Default-Werte in HTTP-Clients sind typischerweise katastrophal — Nodes Default-Fetch-Timeout ist unendlich, die requests-Library in Python hängt gerne für immer.

Fix: Setzen Sie ein explizites Timeout-Budget pro Aufruf. Für interne Services sollten Sie alles über 500 ms als pathologisch betrachten. Für externe Services entscheiden Sie pro Abhängigkeit — vielleicht 3 Sekunden für das Payment-Gateway, 10 Sekunden für den langsamen ERP-Batch-Endpoint. Propagieren Sie dann das verbleibende Budget entlang der Aufrufkette: Wenn dem Aufrufer noch 2 Sekunden bleiben und dieser Aufruf schnell sein soll, setzen Sie ein enges Timeout.

Und entscheidend: Wenn ein Timeout feuert, bedeutet das nicht, dass die Operation nicht stattgefunden hat. Es bedeutet, dass Sie es nicht wissen. Ihre Recovery-Logik muss „wir wissen nicht, ob es passiert ist“ als First-Class-Zustand behandeln — was uns zurück zur Idempotenz aus Punkt 1 führt.

5. Keine Observability über Grenzen hinweg

Ihr System ruft das ERP, das ERP ruft ein Legacy-SAP-Modul, das SAP-Modul ruft eine Datenbank. Etwas geht kaputt. Im Jahr 2026 sehen wir immer noch regelmäßig Teams, die das debuggen, indem sie drei separate Log-Dateien von drei separaten Betriebsteams durchgrep-en und versuchen, aus unpassenden Uhren eine Zeitachse zu rekonstruieren.

Der Fix ist Distributed Tracing. Eine einzige Correlation-ID (W3C Trace Context ist der Standard — der traceparent-Header) wird am äußersten Einstiegspunkt generiert und durch jeden Aufruf propagiert. Jede Log-Zeile trägt die ID. Jeder ausgehende HTTP-, gRPC-, Datenbank- oder Queue-Aufruf taggt sie.

Sie brauchen keine volle APM-Plattform, um anzufangen. Eine disziplinierte correlationId in Ihren strukturierten Logs, über Services hinweg durchsuchbar, bringt Ihnen 80 % des Nutzens. Graduieren Sie zu OpenTelemetry, wenn das Volumen es rechtfertigt.

Der gemeinsame Nenner

Jeder dieser Fixes existiert, weil jemand in der Produktion eine harte Lektion gelernt hat. Sie sind nicht neuartig — das Outbox Pattern wird seit 15 Jahren beschrieben, Idempotency Keys stehen in jeder ernsthaften API-Spec, Distributed Tracing ist Table Stakes. Aber sie tauchen in Greenfield-Enterprise-Code selten auf, bis der erste echte Vorfall sie erzwingt, typischerweise um 3 Uhr morgens.

Der Architecture-first-Ansatz ist simpel: Schreiben Sie diese Dinge ins Design-Dokument, bevor die erste Zeile Integrationscode geschrieben wird. Wenn jemand im Team nicht verteidigen kann, warum jedes dieser fünf Dinge im Design ist (oder nicht ist), sind Sie mit dem Design noch nicht fertig.