Schnittstellen überdauern Implementierungen

Was ein System nach außen zeigt, bleibt länger als das, was innen arbeitet. Diese Geschichte handelt von einem Moment, in dem dieser Unterschied plötzlich zählte. Sie ist bewusst allgemein gehalten — ohne Anbieter, ohne Kunden, ohne Zeitpunkt.

Situation

Ein externer API-Anbieter, auf dem ein System aufsetzte, wurde ersetzt. Über die Zeit hatten sich Millionen bestehender Datensätze angesammelt, die dem alten Anbieter folgten. Der neue Anbieter bot dieselbe Fähigkeit, aber in einer anderen, mit der alten nicht verträglichen Struktur. Es galt, das eine durch das andere zu ersetzen, ohne den Bestand zu verlieren.

Ausgangsannahmen

Die naheliegende Sicht war, dass ein Anbieterwechsel vor allem eine Frage des Anschlusses ist: Man tauscht die Quelle und ruft die neue statt der alten auf. Der Aufwand schien im Umschalten zu liegen. Dass die Millionen bereits gespeicherter Datensätze das eigentliche Gewicht trugen, trat erst in den Vordergrund, als die Unverträglichkeit der Strukturen sichtbar wurde.

Problem

Die neue Struktur passte nicht auf die alte. Jedes bestehende Feld, jede Bedeutung musste auf ihr Gegenstück im neuen Modell abgebildet werden — und wo es kein sauberes Gegenstück gab, musste eine Entscheidung getroffen werden. Bei Millionen Datensätzen ist eine solche Abbildung kein einmaliger Handgriff, sondern ein Vorgang, dessen Vollständigkeit und Richtigkeit man belegen muss. Das Problem war nicht das Umschalten, sondern das verlustfreie Übersetzen eines großen Bestands von einer Sprache in eine andere.

Ursache

Die tiefere Ursache lag in einer Verwechslung, die man leicht macht: die Schnittstelle mit dem Anbieter dahinter gleichzusetzen. Der Anbieter ist die Implementierung — austauschbar, vergänglich. Die Schnittstelle und die Daten, die durch sie geflossen und geblieben sind, sind das Beständige. Ein System, das seine eigene Sicht auf die Daten nicht von der zufälligen Form eines Anbieters getrennt hatte, spürte den Wechsel bis in seinen Bestand hinein.

Entscheidung

Die Entscheidung war, die Daten in eine eigene, vom Anbieter unabhängige Form zu bringen und den neuen Anbieter dahinter anzuschließen — die Schnittstelle als das Bleibende zu behandeln, die Implementierung als das Wechselbare. Nicht der Anbieter bestimmt die Form des Bestands, sondern das System.

Umsetzung

Der alte Bestand wurde auf das neue Modell abgebildet — Bedeutung für Bedeutung, nicht Feld für Feld aus Gewohnheit. Die Migration lief in prüfbaren Schritten, und jeder Schritt wurde verifiziert: Stimmt das Übersetzte mit dem Ursprung überein? Erst wenn die Prüfung stand, galt ein Teil als übernommen. Die Abbildung, die Migration und die Verifikation waren drei getrennte, bewusste Arbeiten — nicht ein hastiges Umschalten.

Trade-offs

Die Daten vom Anbieter zu entkoppeln und einen großen Bestand geprüft zu übersetzen, kostet erheblich mehr als ein direktes Umschalten. Man baut eine Übersetzungsschicht und verifiziert Millionen Datensätze, statt einfach die Quelle zu tauschen. Der Preis kauft die Unabhängigkeit vom nächsten Anbieterwechsel und die Gewissheit, nichts verloren zu haben. Anders würden wir es nur bei einem kleinen, unkritischen Bestand handhaben, dessen Verlust verschmerzbar und dessen erneute Beschaffung billig wäre.

Was wir gelernt haben

Schnittstellen überdauern Implementierungen. Der Anbieter hinter einer Schnittstelle ist austauschbar; die Daten, die durch sie geflossen und geblieben sind, sind es nicht. Wer seine Sicht auf die Daten an die Form eines konkreten Anbieters bindet, macht das Vergängliche zur Grundlage des Beständigen — und zahlt beim ersten Wechsel dafür. Die eigene, unabhängige Form der Daten ist keine Kür, sondern die Vorsorge dagegen, dass eine fremde Entscheidung den eigenen Bestand erschüttert.

Wie das Batunet verändert hat

Seither trennen wir bewusst zwischen der Schnittstelle, die bleibt, und der Implementierung, die geht. Wir bringen Daten in eine Form, die dem System gehört, nicht dem Anbieter — und behandeln jeden externen Dienst als etwas, das man eines Tages ersetzen wird. Ein Anbieterwechsel ist damit kein Erdbeben mehr, sondern ein geplanter Vorgang hinter einer Grenze, die hält.

Weiterführend

• Guide: API Design für langlebige Systeme — warum die Vertragsfläche das Langlebigste ist und man das Innere frei ändern können sollte.
• Guide: API-Versionierung ohne Kunden zu brechen — Schnittstellen weiterentwickeln, ohne den Bestand zu verletzen.
• Guide: Zero-Downtime-Datenbankmigrationen — große Bestände geprüft und umkehrbar migrieren.
• Guide: Software, die in zehn Jahren noch läuft — warum das Beständige und das Vergängliche zu trennen sind.

Grundlage ist die Batunet Engineering Method: das Beständige vom Wechselbaren trennen, in prüfbaren Schritten migrieren, Vollständigkeit belegen.

Ein Anbieter ist geliehen; die Daten, die durch ihn geflossen sind, bleiben. Wer beides verwechselt, baut sein Beständiges auf etwas Vergänglichem.