Gateway, Routing & Resilienz

Szenario

Sieben Anwendungen rufen direkt Anbieter-APIs auf, jede mit eigenem Schlüssel und eigener Retry-Logik. Ihr führt ein Gateway ein. Im Entwurf soll das Gateway zusätzlich die System-Prompts aller Anwendungen halten, „damit Prompt-Änderungen zentral gepflegt werden können“.

Anforderungen

• Wie schneidest du die Verantwortung?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Anmeldedaten, Quoten, Retry- und Timeout-Politik sowie Telemetrie ins Gateway; System-Prompts bleiben beim jeweiligen Anwendungsteam und dessen Release-Artefakt. Richtig. Zentralisiert gehört, was für alle Aufrufer identisch ist. Ein fachlicher Prompt gehört zum Produkt — im Gateway würde jede Produktänderung das gemeinsame Bauteil anfassen und dessen Änderungsrisiko auf alle sieben Anwendungen ausdehnen.
2. Plausibler Fehlweg: Alles zentralisieren, auch die Prompts — eine Stelle ist einfacher zu betreiben als sieben. Das verwechselt Betriebsaufgaben mit Produktinhalt. Das Gateway würde bei jedem Prompt-Feinschliff deployt; sein Änderungsrisiko trifft dann alle Anwendungen gleichzeitig, obwohl nur eine etwas wollte.
3. Plausibler Fehlweg: Kein Gateway, stattdessen eine gemeinsame Client-Bibliothek in allen sieben Anwendungen. Eine Bibliothek kann Verhalten vereinheitlichen, aber keine Quote oder ein Budget durchsetzen und keine Anmeldedaten aus den Anwendungen heraushalten — sie wirkt nur, wenn alle die aktuelle Version einsetzen, und ist damit kein Kontrollpunkt.
4. Plausibler Fehlweg: Das Gateway auf reines Schlüsselmanagement beschränken und Retries in den Anwendungen lassen. Damit bleibt der gefährlichste Teil verstreut: Unkoordinierte Retries aus sieben Anwendungen sind genau der Mechanismus, der unter Last die gemeinsame Anbieterquote sprengt.

Szenario

Ein Anbieterschlüssel wurde versehentlich in einem Repository veröffentlicht und musste sofort rotiert werden. Der Wechsel dauerte einen halben Tag, weil derselbe Schlüssel in vier Anwendungen, zwei Batch-Jobs und einer Notebook-Umgebung lag. Die Kostenzuordnung pro Team war schon vorher nicht möglich.

Anforderungen

• Welche Struktur verhindert die Wiederholung am wirksamsten?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Anbieterschlüssel ausschließlich im Gateway halten; Anwendungen bekommen eigene, kurzlebige interne Anmeldedaten pro Dienst, die dort widerrufbar sind und die Kostenzuordnung tragen. Richtig. Damit gibt es genau einen Ort mit dem teuren Geheimnis, ein kompromittiertes Anwendungs-Anmeldedatum ist einzeln widerrufbar, und die Zuordnung entsteht als Nebenprodukt der Identität statt als nachträgliche Schätzung.
2. Plausibler Fehlweg: Pro Anwendung einen eigenen Anbieterschlüssel ausgeben — zentral im Gateway versioniert und unverändert auf alle Fehlerklassen und Anbieter angewendet sowie ohne anwendungsspezifische Idempotenz- oder Qualitätsprüfung automatisch durchgesetzt. Das begrenzt den Radius eines Lecks und ermöglicht Zuordnung, verteilt aber weiterhin Anbietergeheimnisse über alle Anwendungen — die Rotation bleibt eine Suchaktion, nur mit mehr Objekten.
3. Plausibler Fehlweg: Den Schlüssel in einem Secret-Manager ablegen und alle Anwendungen ihn dort lesen lassen. Das verbessert die Ablage deutlich, aber der Schlüssel liegt zur Laufzeit weiterhin im Speicher jeder Anwendung. Ein einziger kompromittierter Dienst betrifft alle, und die Zuordnung pro Team entsteht dadurch immer noch nicht.
4. Plausibler Fehlweg: Ausgehenden Verkehr per Netzwerkregel auf den Anbieter beschränken, damit ein geleakter Schlüssel von außen unbrauchbar ist. Eine sinnvolle ergänzende Maßnahme, aber sie beantwortet keine der beiden Fragen: Der Schlüssel liegt weiter verstreut, die Rotation bleibt langsam und die Kosten bleiben unzuordenbar.

Szenario

Ein Dienst wiederholt jeden fehlgeschlagenen Modellaufruf dreimal. Die Auswertung zeigt: Ein Drittel aller Retries entfällt auf Anfragen, deren Kontext das Modelllimit überschreitet, ein weiteres Drittel auf Drosselungsantworten des Anbieters, der Rest auf sporadische Serverfehler. Die Anbieterrechnung steigt, die Erfolgsquote kaum.

Anforderungen

• Wie stellst du die Retry-Regel um?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Nach Fehlerklasse trennen: Limit-Überschreitungen sofort ohne Wiederholung zurückgeben, Drosselung mit Wartezeit und Streuung wiederholen, Serverfehler begrenzt wiederholen. Richtig. Nur Fehler, deren Ursache außerhalb der Anfrage liegt, können durch Warten verschwinden. Eine Kontextüberschreitung ist bei jedem Versuch identisch — dort ist der Retry reine Verschwendung und verdeckt einen Anwendungsfehler.
2. Plausibler Fehlweg: Die Anzahl der Versuche von drei auf eins senken — zentral im Gateway versioniert und unverändert auf alle Fehlerklassen und Anbieter angewendet sowie ohne anwendungsspezifische Idempotenz- oder Qualitätsprüfung automatisch durchgesetzt. Das dämpft die Kosten, behält aber die falsche Logik: Aussichtslose Wiederholungen laufen weiter, und bei echter Drosselung ist ein einziger schneller Nachversuch oft zu wenig.
3. Plausibler Fehlweg: Retries beibehalten, aber bei Kontextüberschreitung den Kontext automatisch kürzen und erneut senden. Das versteckt einen Anwendungsfehler hinter einer stillen inhaltlichen Änderung: Die Anfrage wird beantwortet, aber auf Basis eines beschnittenen Kontexts, ohne dass jemand die Qualitätsminderung sieht. Kürzen ist eine bewusste Produktentscheidung, kein Fehlerbehandlungspfad.
4. Plausibler Fehlweg: Alle Retries entfernen und Fehler direkt an den Nutzer geben. Zu grob. Sporadische Serverfehler und kurze Drosselungen sind genau die Fälle, in denen ein maßvoller Nachversuch die Erfolgsquote ohne nennenswerte Zusatzlast hebt.

Szenario

Nach einer sechzigsekündigen Anbieterstörung bricht euer Dienst erneut zusammen, sobald der Anbieter wieder antwortet. Die Auswertung zeigt eine scharfe Lastspitze exakt eine, zwei und vier Sekunden nach der Erholung. Die Klienten nutzen exponentielles Backoff mit festen Wartezeiten.

Anforderungen

• Was ist die Ursache und die Korrektur?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Die festen Wartezeiten synchronisieren alle Klienten auf dieselben Zeitpunkte — zufällige Streuung in die Wartezeit aufnehmen und zusätzlich den Anteil der Retries an der Gesamtlast über ein Retry-Budget begrenzen. Richtig. Die Spitzen genau bei den Backoff-Stufen sind die Signatur synchronisierter Klienten. Streuung verteilt die Wiederkehr über die Zeit, das Budget verhindert, dass Wiederholungen die Erholung erneut überrollen.
2. Plausibler Fehlweg: Die Backoff-Basis von einer auf zehn Sekunden erhöhen. Das verschiebt die Spitze nur nach hinten und macht sie nicht kleiner: Alle Klienten treffen dann synchron nach zehn Sekunden ein. Die Synchronisation ist das Problem, nicht der Zeitpunkt.
3. Plausibler Fehlweg: Kapazität dauerhaft erhöhen, damit die Wiederkehr-Spitze aufgefangen wird. Das dimensioniert den Normalbetrieb auf eine selbst erzeugte Spitze und ist teuer. Die Spitze entsteht aus dem Klientenverhalten und lässt sich dort billiger beseitigen.
4. Plausibler Fehlweg: Nach einer Störung alle Klienten neu starten, damit ihre Timer auseinanderlaufen. Ein zufälliger Nebeneffekt, kein Mechanismus: Ein koordinierter Neustart synchronisiert die Timer eher, und im nächsten Vorfall ist niemand da, der zur richtigen Sekunde neu startet.