Expand and Contract
Expand and Contract ist ein Vorgehen, um laufende Software umzubauen, ohne sie abzuschalten: Erst existieren alte und neue Variante gleichzeitig, dann wird die alte entfernt. Das Muster wird vor allem bei Datenbanken und Schnittstellen zwischen Programmen eingesetzt.
Große Online-Dienste laufen rund um die Uhr. Trotzdem muss ihr Programmcode ständig verändert werden, etwa wenn ein Datenfeld einen neuen Namen bekommt. Wer beides gleichzeitig umstellt, riskiert, dass der Dienst für alle Nutzer ausfällt. Expand and Contract ist eine Vorgehensweise, die genau das vermeidet. Man baut das Neue zuerst zusätzlich zum Alten auf, lässt beides eine Zeit lang nebeneinander bestehen und entfernt das Alte erst ganz am Schluss. Der Name beschreibt diese Bewegung: erst ausdehnen, dann wieder zusammenziehen.
Umbauen bei laufendem Betrieb
Ein Dienst wie ein Online-Shop oder ein Chatbot besteht aus vielen Programmteilen, die miteinander reden. Diese Teile werden nie alle in derselben Sekunde aktualisiert. Während einer Aktualisierung läuft ein Teil der Server bereits mit der neuen Version, ein anderer noch mit der alten. Wenn beide Versionen unterschiedliche Annahmen über die Daten haben, gibt es Fehler. Expand and Contract sorgt dafür, dass beide Versionen zu jedem Zeitpunkt funktionieren.
Der Nutzen ist vor allem wirtschaftlich. Früher plante man für solche Umbauten ein Wartungsfenster, oft nachts. Der Dienst war dann für Stunden nicht erreichbar. Bei einem weltweiten Angebot gibt es aber keine Nachtzeit, in der niemand online ist. Jede Ausfallminute kostet Umsatz und Vertrauen.
Dazu kommt ein Sicherheitsaspekt. Weil die alte Variante die ganze Zeit funktionsfähig bleibt, kann man jederzeit zurückschalten. Geht bei der Umstellung etwas schief, verliert man Stunden statt Tage. Ohne dieses Muster ist ein Rückweg oft gar nicht mehr möglich, sobald die Daten einmal umgeschrieben wurden.
Die drei Phasen des Umbaus
In der Expand-Phase wird nur hinzugefügt, nie entfernt. Soll etwa eine Datenbankspalte namens « telefon » künftig « telefonnummer » heißen, legt man die neue Spalte einfach zusätzlich an. Die alte Spalte bleibt unangetastet. Danach schreibt das Programm eine Zeit lang in beide Spalten gleichzeitig und liest bei Bedarf aus der alten. In dieser Phase kann nichts kaputtgehen, weil alle bestehenden Programmteile weiter ihre gewohnte Spalte vorfinden.
Es folgt die Migrationsphase. Vorhandene Altdaten werden in die neue Spalte kopiert, meist in kleinen Portionen im Hintergrund. Anschließend stellt man das Lesen schrittweise auf die neue Spalte um. Erst wenn alle Programmteile nachweislich nur noch die neue Variante nutzen, ist die Umstellung abgeschlossen.
Die Contract-Phase räumt auf: Die alte Spalte wird gelöscht, ebenso der Code, der beide Varianten gleichzeitig bedient hat. Dieser Schritt ist der unbeliebteste, weil er nichts Sichtbares bringt. Genau deshalb wird er häufig vergessen. Das Ergebnis sind Systeme voller halb fertiger Umbauten, in denen niemand mehr weiß, welche Spalte die richtige ist. Ein Umbau nach diesem Muster gilt erst als fertig, wenn auch die Contract-Phase erledigt ist.
Vom Datenbankfeld bis zur API-Version
Am häufigsten trifft man das Muster bei Datenbanken. Fast jede Umbenennung oder Umstrukturierung in einem produktiven System läuft nach diesem Schema ab. Ähnlich ist es bei Schnittstellen, sogenannten APIs, über die fremde Programme auf einen Dienst zugreifen. Ein neues Feld darf man ergänzen, ein bestehendes nicht einfach streichen, weil sonst die Programme anderer Firmen abstürzen.
Auch bei KI-Produkten spielt das eine Rolle. Wenn ein Anbieter ein Sprachmodell durch eine neue Version ersetzt, bleibt die alte Version meist monatelang parallel erreichbar. Entwickler bekommen eine Frist und eine Ankündigung, dass die alte Version abgeschaltet wird. Diese Ankündigung ist nichts anderes als die angekündigte Contract-Phase.
Ein verwandter Begriff ist Feature Flag: ein Schalter im Code, mit dem man eine neue Funktion für einzelne Nutzergruppen an- und ausschalten kann. Feature Flags steuern, wer das Neue sieht. Expand and Contract regelt dagegen, wie Daten und Schnittstellen den Übergang überstehen. In der Praxis werden beide oft zusammen eingesetzt.