Daher ist mit Einführung von Instant Payments in Europa nach dem Autorisierungsprozess für Kartenzahlungen auch die Echtzeitüberweisung zu einem Einsatzbereich unterbrechungsfreier Systeme geworden.
Kommen wir zunächst zum Begriff der Unterbrechungsfreiheit. Ein unterbrechungsfreier Betrieb wird durch zwei verschiedene Eigenschaften beschrieben:
- Vermeidung geplanter Nichtverfügbarkeit
Das System ist im Normalbetrieb permanent funktionsbereit. Es hat also keine periodischen Zeiten eingeschränkter Funktionalität, wie bei Tagesende oder Reorganisation.
Das System ist so konstruiert, dass auch Releasewechsel während des Betriebs durchgeführt werden können und keine Downtime verursachen.
- Reduzierung der ungeplanten Nichtverfügbarkeit
Das System ist auch bei Fehlerszenarien hoch verfügbar. Es gewährleistet also mit hoher Wahrscheinlichkeit den Betrieb trotz Ausfalls einzelner Komponenten. Diese Ausfallwahrscheinlichkeit wird berechnet oder gemessen als das Verhältnis der Produktionszeit zur Laufzeit, also der Zeit inklusive der Ausfallzeit, beispielsweise 99,99 Prozent. Insbesondere die Robustheit in Überlastszenarien ist hier von Interesse. Obwohl jedes System seine Grenzen hat, ist es eben ein Unterschied, ob jenseits der Belastungsgrenze alles zusammenbricht oder nur die zusätzliche Last nicht im Rahmen der Vorgaben abgearbeitet werden kann.
Die Begeisterung für das Thema lässt meistens beim Betrachten der Kosten erheblich nach. Es lohnt daher, architektonische Antworten zu finden und nicht alles nur auf die Infrastruktur zu verlagern. Dennoch wird auch die beste Software nur dann laufen können, wenn die Systemumgebung verfügbar ist. Ich möchte hier nicht näher auf hochverfügbare Infrastruktur, Betriebssysteme, Datenbanksysteme und Message Broker eingehen – all dies ist Grundvoraussetzung für ein unterbrechungsfreies Gesamtsystem. Ich möchte den Fokus auf die Softwarearchitektur legen. Diese kann es ermöglichen, Verfügbarkeitsanforderungen gezielt umzusetzen und dabei die Kosten im Griff zu behalten.
Da Hochverfügbarkeit teuer ist, müssen zuallererst die kritischen Prozesse identifiziert werden. Es gilt also, die Frage zu beantworten, welche Prozesse wirklich immer funktionieren müssen und welche durchaus auch nachgeholt werden können. Im Echtzeitzahlungsverkehr sind beispielsweise die Sammlerprozesse weniger kritisch als die Einzelzahlungen.
Falls große Komponenten unter die kritischen Prozesse fallen, sollte analysiert werden, ob diese überbrückt werden können. Kann also eine alternative Komponente die kritischen Aufgaben einer großen nicht hochverfügbaren Komponente für die Zeit des Ausfalls ersetzen? Im Zahlungsverkehr kann etwa das Buchungssystem ein derartiges großes, nicht hochverfügbares System sein und die Onlinedisposition der kritische Prozess, den es zu überbrücken gilt.
Zahlungsverkehr als Ganzes ist selbstredend kein zustandsloser Prozess: Geld kann leider immer nur einmal ausgegeben werden, der Kontostand ist also ein relevanter Zustand und eine Bankensoftware muss dies natürlich genau abbilden können. Das führt in unserem Fall immer zum Einsatz von Datenbanken und zum Bedarf einer Persistenz vor und nach jeder relevanten Zustandsänderung. Gerade das Design des Datenbankmodells gibt den Ausschlag darüber, ob wir unser Ziel erreichen oder nicht. Hochverfügbare Prozesse sollen mit stabilen bzw. migrationsfreien Datenstrukturen arbeiten. Nur so kann vermieden werden, dass kritische Prozesse für eine Änderung des Datenbankschemas heruntergefahren werden müssen.
Bleibt das Thema Robustheit. In der Wissenschaft spricht man auch von Resilienz, wenn beschrieben wird, dass Störungen oder Teilausfälle von technischen Systemen nicht dazu führen, dass diese vollständig versagen. Im Zahlungsverkehr können solche Störungen Lastspitzen oberhalb vereinbarter Grenzen sein oder Umsysteme, die nicht so schnell antworten wie vereinbart. Auch Ausfälle bei Geschäftspartnern und damit ausfallende Quittungen in größerer Menge können Ausfälle verursachen. Wir haben in der reaktiven Programmierung ein Paradigma gefunden, das die gewünschte Robustheit durch die Orientierung an Datenflüssen ermöglicht. Eine Überlast kann so auf betroffene Bereiche gekapselt werden und dem störungsfreien Betrieb der restlichen Daten – in unserem Falle Zahlungen – steht nichts im Wege.
Autor: Thomas Riedel