Hauptgedanke

Ein E-Mail-Gateway tauscht man aus, indem man einen Zugangsschlüssel ändert. Einen SMS-Anbieter ebenso. Ein Sprachmodell auch, solange das dauerhafte Gedächtnis, der fachliche Kontext und die Entscheidungen im Produkt bleiben: Diese Bausteine behalten zwischen zwei Aufrufen nichts.

Eine Datenbank ist etwas anderes. Sie hält den dauerhaften Zustand des Systems. Sie zu ersetzen heißt, die Daten zu migrieren, ihre Konsistenz zu sichern, den Wiederanlauf vorzubereiten, die Sicherungen zu verwalten, manchmal die Replikation.

Austauschbarkeit ist also nicht binär, sie ist ein Gradient — und was ihn abstuft, ist nicht der fachliche Wert des Bausteins, sondern der Zustand, den er festhält.

Warum das wichtig ist

Zwei Kriterien überlagern sich, und man verwechselt sie. Das erste sagt, was man abgeben darf — trägt der Baustein den Wert? Das zweite sagt, was es kosten wird — hält der Baustein den Zustand?

Ein Baustein kann für den Kern des Produkts völlig belanglos sein und trotzdem zu denen gehören, die sich am schwersten austauschbar machen lassen. Genau das ist bei der Datenbank der Fall, und deshalb ist dieser Fall schwieriger als alle anderen.

Nuancen und Grenzen

Der Zustand ist nicht die einzige Kostenquelle: Eine tiefe Integration in den Code kann einen Austausch auch ohne Zustand schwierig machen.

Und völlige Zustandslosigkeit gibt es nie — ein Messaging-Dienst bewahrt Verläufe, Absenderreputationen, Sperrlisten.

Offene Fragen

• Wie schätzt man die Kosten eines Austauschs im Voraus ab, ohne ihn durchzuführen?