„Ihr Kafka-Cluster ist ein Schattenmonolith“

Die Finanzbranche hat drei Jahrzehnte damit verbracht, sich aus hochgradig gekoppelten Mainframe-Architekturen zu befreien. Dort war jede noch so kleine Änderung so eng mit anderen Systemen verzahnt, dass sie die Abstimmung zwischen zahlreichen Teams und das Einfrieren mehrerer Release-Zyklen erforderte. In vielen Finanzinstituten, die Kafka heute in großem Maßstab einsetzen, ist genau diese Kopplung zurückgekehrt – nur dass sie dieses Mal unsichtbar und damit schwerer zu kontrollieren ist. Unsichtbare Kopplung taucht nicht in Architekturdiagrammen auf. Sie zeigt sich erst dann, wenn Systeme ausfallen und Vorfälle analysiert werden.

von Derek Troy-West, Factor House

Der genaue Begriff für das, was viele regulierte Institutionen heute betreiben, lautet „Schattenmonolith“. Ein Monolith definiert sich nicht durch seine Topologie, sondern durch seine Abhängigkeiten – insbesondere dadurch, ob diese Abhängigkeiten explizit, erzwungen und sichtbar oder implizit, konventionell und verborgen sind. Ein Kafka-Cluster mit 300 Topics, einer Schema-Registry ohne Durchsetzung und ohne formelles Topic-Ownership-Modell sowie Consumer-Gruppen mit unklarer, historisch gewachsener Verteilung ist ein verteilter Monolith.

Ein verteilter Monolith ist schlimmer als das Original, denn beim Mainframe wusste zumindest jeder, wo der Systemzustand lag.“

Was einen Schattenmonolithen ausmacht

Gemeinsam genutzter veränderbarer Zustand ohne erzwungene Verträge: Topics sind in Kafka grundsätzlich clusterweit verfügbar und damit global nutzbar. Schema-Registries dienen der Verwaltung, doch in den meisten Produktionsumgebungen arbeiten sie im Rückwärts- oder Vorwärts­kompatibilitäts­modus und fungieren eher als Dokumentation denn als Durchsetzungsmechanismus.

Das Ergebnis ist eine Schema-Drift: Ein Produzent aktualisiert ein Feld, nachgelagerte Consumer arbeiten jedoch weiterhin mit ihrer lokal gebundenen Schemaversion.“

Dadurch produziert die Pipeline tagelang oder sogar wochenlang Ausgaben, die die Formatvalidierung bestehen, jedoch semantisch nicht korrekt sind. Im Kontext von Zahlungsverkehr oder Risikoberichterstattung stellt dieses Zeitfenster eine Kontrolllücke dar.

Implizite teamübergreifende Abhängigkeiten: In einem gut verwalteten verteilten System werden Teamgrenzen durch explizite Schnittstellen mit Versionen, Eigentümern, SLAs und Lifecycle-Regeln festgelegt und technisch abgesichert. In einem Schattenmonolith-Kafka-Cluster existiert der Abhängigkeitsgraph hingegen nicht als explizites Artefakt, sondern nur implizit – im institutionellen Gedächtnis oder in Ad-hoc-Code- und Konfigurationssuchen (z. B. grep über Consumer-Konfigurationen und Deployment-Definitionen).

Unbegrenzter Wirkungsradius: Ohne auf Broker-Ebene durchgesetzte Quoten pro Topic und pro Producer wird die Ressourcenzuweisung faktisch über implizite Konventionen gesteuert. Ein einzelner Producer, der sich fehlerhaft verhält, bleibt nicht isoliert. Ressourcenkonflikte auf Broker-Ebene wirken sich über einzelne Topics hinaus auf den gesamten Cluster aus.

Warum dies im Finanzsektor anders ist

Fällt ein Schattenmonolith in einem nicht regulierten Umfeld aus, sind die Kosten operativer Natur. Fällt er hingegen in einem von der BaFin, der FINMA oder der FMA regulierten Institut aus, sind die Kosten struktureller Natur.

Integrität des Audit-Trails: Laut MaRisk AT 7.2 muss eine lückenlose und überprüfbare Dokumentation der IT-Prozesse und Datenflüsse vorliegen, die risikorelevante Geschäftsfunktionen unterstützen. Die BAIT verlangen von den Instituten, die Rückverfolgbarkeit von Transaktionen über ihre gesamte Verarbeitungskette hinweg nachzuweisen. Das FINMA-Rundschreiben 2023/1 erlegt Schweizer Instituten gleichwertige Verpflichtungen auf. Die Rekonstruktion einer Transaktion in einem Schattenmonolith-Cluster erfordert die Korrelation von Offsets der Consumer-Gruppe, Producer-Timestamps, Broker-Protokollen und der Schema-Registry-Historie über mehrere getrennte Datenquellen hinweg – ohne gemeinsames Zeitmodell oder eine einheitliche Abfrageschnittstelle.

Schema-Drift als stiller Compliance-Verstoß: Ein Producer-Team erweitert ein Feld der Transaktionskategorie von zwei auf vier Zeichen, um einen neuen Produkttyp zu berücksichtigen. Die Änderung ist nach der Definition von Avro abwärtskompatibel. Ein nachgelagerter Consumer, der die Pipeline für die aufsichtsrechtliche Berichterstattung speist, ist jedoch gegen eine frühere Schemaversion implementiert bzw. gebunden. Er verarbeitet den abgeschnittenen Wert, verwirft die zusätzlichen Zeichen stillschweigend und erzeugt weiterhin eine Ausgabe, die die Formatvalidierung besteht, übermittelt wird und inhaltlich falsch ist.

Selbst wenn die ungenaue aufsichtsrechtliche Berichterstattung auf einem technischen Fehler beruht, gilt sie als Verstoß gegen MaRisk und BAIT.“

Konflikt mit der DSGVO: Das append-only Log von Apache Kafka steht in einem strukturellen Spannungsverhältnis zum Recht auf Löschung. Das Löschen von Verschlüsselungs­schlüsseln sowie die Verschlüsselung auf Feldebene mit einer subjektbezogenen Schlüsselrotation führen zu zusätzlicher Infrastrukturbelastung, was den nutzenden Teams möglicherweise nicht bewusst ist.

Ein Löschantrag löst eine Rotation des Verschlüsselungs­schlüssels aus.“

Ein Consumer, der entschlüsselte Werte in einem lokalen Speichersystem zwischenspeichert, verfügt nun über Daten, die nicht mehr aus dem Quell-Topic rekonstruiert werden können.

Diagnosemarker

Mithilfe eines Produktionsclusters lassen sich diese Fragen beantworten, ohne dass spezielle Tools erforderlich sind:

1. Lässt sich jedes Topic in Ihrem Cluster einem einzigen verantwortlichen Team zuordnen, das für dessen Schema, Aufbewahrungsrichtlinie, Lifecycle-Ende und Löschung zuständig ist? In einem Schattenmonolithen sind typischerweise 30 bis 60 Prozent der Topics nicht eindeutig einem Team zugeordnet.
2. Wird die Schemavalidierung an der Broker-Grenze so durchgesetzt, dass ein Produzent, der eine nicht konforme Nachricht sendet, abgelehnt wird, bevor die Nachricht in den Cluster gelangt?
3. Wie hoch ist das Verhältnis von aktiven zu insgesamt registrierten Consumer-Gruppen? Verwaiste Gruppen, die registriert sind und committed Offsets gespeichert, aber keine aktiven Mitglieder haben, sind ein Relikt undokumentierter Abhängigkeiten.
4. Können Sie sofort und ohne manuellen Aufwand ein vollständiges und korrektes Diagramm aller Beziehungen zwischen Producern, Topics und Consumern in Ihrem Cluster erstellen?

Wenn Sie mehr als drei dieser Fragen mit „Nein“ oder „Unsicher“ beantworten, liegen die strukturellen Bedingungen eines Schattenmonolithen vor. Dabei sind unsichere Antworten bedeutender als eindeutige „Nein“-Antworten, denn Unsicherheit bedeutet, dass die Informationen nicht in einer zugänglichen, verbindlichen Form vorliegen. Und in einer regulierten Umgebung ist dies an sich schon die Erkenntnis.

Der Ausweg

Eine Neuprogrammierung ist nicht der Ausweg aus einem Schattenmonolithen. Unternehmen, die versucht haben, diese Probleme durch einen kompletten Neuaufbau ihrer Kafka-Infrastruktur zu lösen, hatten in den meisten Fällen innerhalb von 18 Monaten dieselben Probleme im neuen Cluster.

Das Problem liegt nicht beim Cluster. Es liegt im Fehlen architektonischer Leitplanken, deren Durchsetzung nie Teil des ursprünglichen Cluster-Designs war.“

Die Schemavalidierung sollte effektiv an der Broker-Grenze durchgesetzt werden, idealerweise bereits im Producer über die Integration mit der Schema Registry, sodass nicht konforme Nachrichten gar nicht erst in den Cluster gelangen. In der Praxis sollte die Schema Registry zunächst im Audit- bzw. Compatibility-Check-Modus (non-enforcing) betrieben werden, um die tatsächliche Nichtkonformität sichtbar zu machen, bevor eine schrittweise Durchsetzung erfolgt. Darauf aufbauend sollte die Behebung nach Topic-Kritikalität und Anzahl der Consumer priorisiert werden, während neue Topics sofort durchgesetzt und bestehende Topics nach einem festgelegten Zeitplan migriert werden.

Die Topic-Verantwortung sollte in einer versionskontrollierten Infrastructure as Code abgebildet werden.“

Ein Topic Inventory, also eine strukturierte und maschinenlesbare Aufzeichnung jedes Topics im Cluster, macht den Abhängigkeitsgraphen explizit und abfragbar. Damit entsteht die Grundlage für ein aktives Lebenszyklusmanagement, das der schleichenden Monolithbildung entgegenwirkt.

Die Verzögerung von Consumer-Gruppen sollte als formelles SLA pro Gruppe definiert und nicht als vorübergehende Betriebskennzahl behandelt werden. Für Consumer, die Daten in Risikoberichts- oder aufsichtsrechtliche Berichts-Pipelines einspeisen, ist der Consumer Lag eine geschäftliche Kennzahl mit direkten Auswirkungen auf die Compliance.

Der Abhängigkeitsgraph sollte ein kontinuierlich gepflegtes Plattformartefakt sein, das laufend aktualisiert wird, sobald sich Producer oder Consumer ändern.“

Ein Live-Diagramm ermöglicht eine automatisierte Folgenabschätzung, bevor Schemaänderungen bereitgestellt werden. Es identifiziert jeden aktiven Consumer eines Topics, die Schemaversion, die er jeweils zur Deserialisierung erwartet, sowie etwaige Kompatibilitäts­abweichungen und das zuständige Team für jeden betroffenen Consumer.

Jede dieser Entscheidungen setzt eine organisatorische Voraussetzung voraus: die Erkenntnis, dass die Kafka-Infrastruktur in einem regulierten Institut eine Plattforminfrastruktur ist, die eine zentrale Funktion erfordert.“

Diese muss befugt sein, Schema-Standards durchzusetzen, Topic-Verantwortung zu verlangen, Consumer-SLAs festzulegen und die Modellierung des Wirkungsradius vorzuschreiben.

Der Schattenmonolith ist die kumulierte Folge von Entscheidungen, die einzeln betrachtet vernünftig sind, in ihrer Gesamtheit jedoch kostspielig werden: Dazu gehören Schemavalidierung ohne Durchsetzung, unkontrolliertes Wachstum von Topics ohne aktives Lebenszyklusmanagement und Consumer Lag als operative Kennzahl statt als formal definierte Größe mit klaren SLAs. Angesichts der zunehmend spezifisch durchgesetzten Aufsichtsrahmen von BaFin, FINMA und FMA sind diese Entscheidungen – trotz verfügbarer Tools und etablierter Muster – nur schwer zu rechtfertigen. Derek Troy-West, Factor House