Eine IT-Anwendungslandschaft ist nie monolithisch, auch wenn einzelne Komponenten durchaus diese Eigenschaft besitzen können - hier ein großes CRM-System, da das CMS, dort die Buchhaltungssoftware. In der Regel können diese Systeme unabhängig voneinander operieren, aber manchmal reicht das nicht aus. Denn die Daten, mit denen die Systeme arbeiten, sind nicht immer unabhängig voneinander.

Der Kunde, der im CRM hinterlegt ist, ist derselbe Kunde, für den an anderer Stelle die Rechnungen geschrieben werden. Wenn die Adresse im CRM sich geändert hat, dann sollte das auch bei der Rechnungsstellung berücksichtigt werden. Wenn die Rechnungsstellung eigene Daten führt, die mit dem CRM synchronisiert werden müssen, dann gibt es einen Zeitraum, in dem die Daten der Rechnungsstellung noch nicht wieder identisch zu den Daten des führenden CRM sind. Erst wenn die Synchronisierung abgeschlossen ist, sind die Daten wieder konsistent.

Das bezeichnet man als Eventual Consistency. Im Zeitraum zwischen Veränderung der Daten im führenden System und Veränderung im abhängigen System können Dinge geschehen, die wir eigentlich nicht wollen.

Eventual Consistency ist nicht per se ein Problem. Sie ist obendrein in verteilten Systemen die Regel, nicht die Ausnahme, auch wenn wir so selten mit den negativen Folgen konfrontiert werden, dass wir gerne ignorieren, dass es sie gibt. Aber wenn wir z. B. eine E-Mail verschicken, dann ist die versendete Information nur “eventually consistent”. Erst wenn sie empfangen und auch gelesen wurde, ist die enthaltene Information bei Sender und Empfänger wieder konsistent. Das kann ein guter Grund sein, zum Telefon zu greifen, um Fehlentscheidungen aufgrund nicht synchronisierter Informationsstände zu vermeiden.

Was unterscheidet Telefon und E-Mail? Aus Sicht der IT ihre Eigenschaften als

• synchron bzw. gekoppelt (Telefon) und
• asynchron bzw. entkoppelt (E-Mail).

Eventual Consistency ist also offensichtlich eine Eigenschaft, die mit Entkopplung bzw. Asynchronität ihren Einzug hält. Was A weiß, weiß B noch lange nicht.

Wie oben bereits angedeutet, geht man in den meisten Fällen gar nicht mit Eventual Consistency um. Das ist nicht schlimm, weil oft entweder

• kein Schaden entsteht oder
• selten Schaden entsteht, der aber dem Fachprozess bzw. Geschäft nicht nachhaltig zusetzt.

Wenn also auf einer Rechnung noch die alte Adresse erscheint, dann ist das zwar nicht richtig, aber in der Regel auch nicht weiter schlimm. Das Geld wird trotzdem bezahlt.

Warum dies keine Lösung ist:

Wenn im obigen Beispiel die Sendung an die alte Lieferadresse geschickt wird, liegt der Fall anders. Hierdurch entstehen echte Kosten an verschiedenen Stellen (Neuverpackung und -versand, verzögerte Lieferung und Verärgerung, eventuell gar Verlust des Kunden, Personalkosten für die Fallklärung und -bearbeitung).

Wichtig ist also, die Entscheidung, nichts zu tun, bewusst zu treffen (und keine grundsätzliche Regel daraus zu machen). Ist “nichts tun” keine Lösung, werden andere Antworten gebraucht.

Wenn die Synchronisierung ein zwingend erforderlicher Schritt ist, um Daten über Systemgrenzen konsistent zu halten, dann kann eine Synchronisierung in die Transaktion aufgenommen werden, die die Daten im führenden System verändert. Die Transaktion ist die Klammer, die mehrere Prozessschritte zusammenfasst und sie gemeinsam entweder ganz oder gar nicht abschließt (z. B. eine Sollbuchung immer mit der korrespondierenden Habenbuchung).

Warum dies ebenfalls keine Lösung ist:

Eine Transaktion in einem verteilten System ist komplexer als in einem geschlossenen, lokalen System. Die besondere Herausforderung besteht darin, die Schritte in verschiedenen Anwendungen so zu koordinieren, dass entweder Freigabe (Commit) oder Zurückdrehen der Änderungen (Rollback/Compensation) über Systemgrenzen hinweg funktionieren. Entwurfsmuster, die hier zum Einsatz kommen, heißen Two- oder Three-Phase-Commit und haben mit dem Saga-Pattern einen nahen Verwandten.

Dabei sind diese Entwurfsmuster nicht absolut sicher. Es gibt stets eine letzte Lücke, die bei einer Störung zu einem Scheitern des Prozesses führen kann. Die Wahrscheinlichkeit dafür wird allerdings so gering, dass sie (fast) ignoriert werden kann.

Das Problem der Eventual Consistency schaffen die Entwurfsmuster ohnehin nicht komplett aus der Welt. Wenn ein unabhängiger Prozess vor Abschluss der Synchronisierung auf die noch nicht aktualisierten Daten zugreifen möchte, erhält er den alten Stand, obwohl er vielleicht fachlich schon auf den Prozess folgt, der die Synchronisierung auslöst. Es werden dann weitere Steuerungsmechanismen benötigt, um dieses Problem zu lösen (z. B. globale Semaphore, die Zugriffe auf in Veränderung befindliche Objekte verhindern; siehe auch nächste Variante).

Aus rein algorithmischer Sicht gibt es für die meisten Herausforderungen eine Lösung. Aber dass es einen brauchbaren Algorithmus gibt, ist nur ein Teil der Antwort. Denn jeder zusätzlich benötigte Algorithmus ist ein Kompromiss: Was ich auf der einen Seite an reiner Machbarkeit gewinne, bezahle ich an anderer Stelle durch zusätzlichen Entwicklungsaufwand, höhere Komplexität (und geringere Wartbarkeit), niedrigere Systemperformance (und höhere Transaktionskosten). Das Risiko einer fehlerhaften Fachlichkeit sinkt, aber andere Risiken steigen dafür.

Es gibt heutzutage viele IT-Architekten, die mit den Schultern zucken und sagen: “Ist eben so! Entkoppelte Systeme sind wichtig, also muss man das akzeptieren.” Ihre Empfehlung lautet, die Systeme so zu schneiden, dass Eventual Consistency kein Problem wird. Aber alle Teile eines Anwendungssystems beisammen zu halten, die eine konsistente Sicht auf die Daten brauchen, führt häufig zu sehr großen Komponenten. Große (monolithische) Komponenten sind aber, das haben wir in den letzten Jahrzehnten gelernt, nicht wünschenswert. Außerdem ist das mit dem Schneiden (oder Zusammenlegen) oft gar keine Entscheidung, die noch getroffen werden kann, weil Teile der Gesamtarchitektur schon da und somit Zuständigkeiten und Datenhoheiten schon definiert sind.

Eventual Consistency haftet also eine gewisse Unumgänglichkeit an - in modernen IT-Architekturen sogar in besonderem Maße, weil diese entkoppelt und kleinteilig sein müssen, um die versprochenen Effizienzvorteile zu heben. Weil aber “schön” nicht “schön falsch” werden darf, müssen die oben beschriebenen Lösungsvarianten für das Problem der Eventual Consistency ebenfalls in die Architektur integriert werden. Das geschieht je nach Bedarf einzeln oder auch in Kombination miteinander.

Der Umgang mit Eventual Consistency ist vor allem eines: teuer. Die Gegenmaßnahmen kosten einiges, sowohl in der Konzeption und Entwicklung als auch in der Wartung. Und wenn es doch zu einem fachlichen Fehler aufgrund der technisch begründeten Eventual Consistency kommt, dann ist die Ursachenanalyse schwierig (von der Behebung mal ganz abgesehen).

Das Problem der Eventual Consistency ist also nicht ihr Wirken. Es sind die Maßnahmen, die wir ergreifen müssen, ihr entgegen zu wirken.

Früher war alles besser?

Die Antithese ist einfach: Früher, in Zeiten monolithischer Anwendungen mit großen relationalen Datenbanken, da gab es solche Probleme nicht. Denn früher war alles besser. Das ist genauso richtig wie es falsch ist.

Natürlich ist die Abbildung in einer gemeinsamen Datenbank innerhalb eines monolithischen Systems ein Garant dafür, dass Geschäftsprozesse auf einfache Weise in Transaktionen gekapselt werden können. Die Konsistenz der Daten innerhalb des Monolithen ist gut herstellbar. Aber die Abbildung aller Fachprozesse innerhalb einer gemeinsamen, synchron operierenden Anwendungsarchitektur bringt eben auch all die Schwächen mit sich, die überhaupt erst zu modernen, verteilten Architekturen geführt haben:

• eine im Laufe der Zeit immer schwierigere Wartung,
• hohe Komplexität,
• Wartezustände und Locks,
• Ressourcenhunger und
• schlechte Skalierbarkeit.

Das sind keine gewünschten Eigenschaften einer IT-Anwendung. Aber gibt es nicht vielleicht eine Lösung zwischen diesen Extremen?

Eventual Consistency ist keine wünschenswerte Eigenschaft einer IT-Architektur, wenn Datenkonsistenz über Komponenten hinweg zwingend hergestellt werden muss. Es gibt genügend Konzepte, die mit diesem Problem umgehen können. Allen gemein ist, dass sie einen Kompromiss erfordern. Versucht man, die Eigenschaften einer modernen Architektur dabei vollständig zu erhalten, dann erhöht das die Komplexität und damit Kosten und Risiken. Schraubt man hingegen die architekturellen Ambitionen zurück, so gibt man zwangsläufig einige der Vorteile auf, die eine verteilte, hoch skalierbare Architektur bieten kann. Dafür reduziert sich aber die Komplexität der Lösung.

Persönlich tendiert der Autor zur Variante 5, insbesondere aufgrund der Erfahrungen mit Projekten, bei denen ein maximal entkoppelter Ansatz versucht wurde.

Entweder

• hatten diese erhebliche Probleme mit der Komplexität der technischen Abbildung der fachlichen Anforderungen oder
• es wurden nicht alle nötigen Verfahren implementiert, um die Datenkonsistenz verlässlich herzustellen.

Die Ambitionen in IT-Projekten lösen sich gerne einmal von den Notwendigkeiten und Gegebenheiten der Fachlichkeit. Das ist ein Missverhältnis, das bei der Gestaltung einer Anwendungslandschaft höchst ungesund ist. Eine gute IT-Architektur ist eine, die von uns beherrscht wird und nicht umgekehrt. Die wahre Herausforderung ist es, technischen Idealismus und funktionale Nüchternheit auf die beste Weise zu verheiraten.

Sie möchten sich näher mit dem Thema beschäftigen und eine adäquate Lösung finden?
Sprechen Sie unseren Technology Lead für Data Centric Solutions & AI gerne an.