my AI Tagebuch · Im Grossen

Tag 4: Von «läuft» zu «hält»

Samstag, 31. Oktober 2026 · Michael Andrejews

Am Samstag wurde aus dem System eine Umgebung mit drei Demo-Banken, E-Banking und Lastgenerator. Dann kam der Lasttest, und mit ihm die ehrlichsten Stunden des Projekts. 18 Commits.

Eine Demo, die man anfassen kann

Der Vormittag galt der Sichtbarkeit: drei erfundene Banken in einem gemeinsamen Stack, Monitoring mit Prometheus und Grafana, ein Demo-E-Banking mit Kontoauszügen nach ISO 20022, QR-Rechnungen per Handy-Kamera und ein Generator, der laufend Zahlungen zwischen den Banken erzeugt.

Drei erfundene Banken, ein gemeinsamer Simulator der Plattform. Jede mit eigenem E-Banking.

Eine Zahlung von Bank zu Bank: 0,41 Sekunden bis zur Gutschrift. Rechts erscheint sie live im Konto der Empfängerin.

QR-Rechnung per Kamera erfassen und der Vermögensüberblick mit Depot, Krypto und Sparzielen.

Dasselbe E-Banking auf dem Handy, mit Live-Gutschrift und Zeit bis zum Eingang.

Das war der angenehme Teil. Der Generator hatte aber auch einen Lastmodus.

Was die Last gezeigt hat

Befund	Ursache	Lösung
Bei rund 190 Zahlungen pro Sekunde stockte alles	Ein einziger Prüfpfad für alle Zahlungen, alle Verbindungen warteten auf dieselbe Zeile	Eine eigene Hash-Kette pro Zahlung mit Ankern
Bei 450 pro Sekunde wurden fast 49'000 Zahlungen in fünf Minuten unklar	Zahlungen liefen in die Fristen der Plattform	Zulassungssteuerung: warten vor dem Start, nach 5 Sekunden eine klare Absage
Nach einem Neustart blieben unklare Zahlungen hängen	Kein Mechanismus zum Klären	Wiederholte Statusabfragen, unbekannte Zahlungen sauber abschliessen

Das Ergebnis: 300 Zahlungen pro Sekunde laufen auf einem Entwickler-PC sauber, die Quittung kommt nach 17 Millisekunden. Bei 450 pro Sekunde Überlast gibt es keine einzige unklare Zahlung mehr.

300/sZahlungen pro Sekunde sauber verarbeitet

17 msbis zur Quittung

0unklare Zahlungen bei 450/s Überlast

1,5 smittlere Wartezeit unter Überlast

Gemessen auf einem Entwickler-PC mit drei Banken in einer gemeinsamen Datenbank, Simulator statt echter Plattform. In Produktion hätte jede Bank eigene Server.

Warum dieser Tag der wichtigste war

Jeder dieser Befunde ist ein klassischer Produktionsvorfall. In einem echten Projekt wären sie im Lasttest kurz vor der Einführung aufgefallen, mit Eskalation und Verschiebung. Hier wurden sie an einem Samstagnachmittag gefunden, verstanden, gelöst und in drei Architekturentscheiden dokumentiert.

Bemerkenswert ist, wer was beigetragen hat. Die Agenten haben gemessen, Ursachen eingegrenzt und Lösungen gebaut. Dass unklare Zahlungen im Instant-Verkehr das eigentliche Risiko sind und nicht die Geschwindigkeit, mussten wir vorgeben. Ein schnelles System, das Zahlungen in einen unbekannten Zustand laufen lässt, ist für eine Bank schlechter als ein langsames.

Was danach fehlt

Ehrlich bleibt: Für den Einsatz in einer Bank fehlen die Anbindung an die echte Plattform, die Zertifizierung, Adapter zum Kernbankensystem und ein externer Sicherheitstest. Das sind keine Code-Fragen. Dazu mehr in der Bilanz.

Die Erkenntnis des Tages

Robustheit entsteht nicht beim Bauen, sondern beim Brechen. Mit Agenten wird das Brechen so billig, dass man es endlich früh und oft tun kann.