Ein Rollback macht nicht automatisch alles wieder gut

Ein fehlgeschlagenes Deployment wird oft mit einem einfachen Ablauf verbunden: Version zurückrollen, Dienst neu starten, Incident beenden. Das funktioniert nur in der günstigsten Variante eines Produktionsfehlers: Der neue Code ist fehlerhaft, hat aber noch keine relevanten Zustände verändert.

In realen Systemen ist ein Deployment selten nur ein Austausch von Artefakten. Es kann Datenbankmigrationen ausführen, Nachrichten versenden, Dateien erzeugen, Rechte ändern, Caches befüllen, Workflows starten oder Daten an Drittsysteme übertragen. Der Code-Rollback entfernt diese Wirkungen nicht.

Die entscheidende Unterscheidung lautet daher: Rollback ist eine Deployment-Maßnahme. Recovery ist die Wiederherstellung eines gewünschten System- und Geschäftszustands.

Drei Dinge, die häufig vermischt werden

Code-Rollback

Beim Code-Rollback wird eine frühere Version einer Anwendung, eines Containers, einer Funktion oder einer Konfiguration aktiviert. Das Ziel ist, fehlerhaftes Laufzeitverhalten zu stoppen oder auf einen bekannten Softwarestand zurückzukehren.

Das ist sinnvoll, wenn etwa:

• eine neue API-Implementierung Fehler produziert,
• eine Konfiguration zu Timeouts führt,
• ein Feature Flag falsch ausgewertet wird,
• eine neue Abhängigkeit den Dienst instabil macht.

Der Rollback beantwortet aber nur diese Frage: Welche Software läuft jetzt? Er beantwortet nicht: Welche Veränderungen hat die vorherige Software bereits ausgelöst?

Daten-Recovery

Daten-Recovery korrigiert oder rekonstruiert persistente Daten. Das kann ein Restore aus einem Backup, Point-in-Time-Recovery, ein gezieltes Korrekturskript oder eine fachlich geprüfte Datenmigration sein.

Ein Rollback kann Daten-Recovery sogar erschweren. Ein typisches Beispiel:

1. Release A verwendet das Schema orders.status als Textfeld.
2. Release B führt eine normalisierte Statushistorie ein, migriert vorhandene Werte und entfernt die alte Spalte.
3. Nach dem Deployment von B treten Fehler auf.
4. Der Dienst wird auf Release A zurückgesetzt.

Release A erwartet eine Spalte, die nicht mehr existiert. Selbst wenn die Anwendung startet, kann sie mit den neuen Datenmodellen nichts anfangen. Der Code ist alt, die Daten sind neu.

Business-Recovery

Business-Recovery geht noch weiter. Sie korrigiert die fachlichen Folgen einer technischen Änderung.

Wenn ein fehlerhaftes Release Rechnungen doppelt versendet, Lieferaufträge erzeugt oder eine Preissenkung an einen Marktplatz überträgt, reicht ein Datenbank-Restore nicht aus. Möglicherweise sind E-Mails zugestellt, Zahlungen eingezogen, Lagerprozesse gestartet oder Kund:innen informiert worden.

Dann braucht es fachliche Entscheidungen:

• Welche Vorgänge werden storniert, welche korrigiert?
• Welche bereits ausgelösten Aktionen dürfen nicht einfach rückgängig gemacht werden?
• Wer entscheidet bei widersprüchlichen Datenständen?
• Wie werden Kund:innen, Fachabteilungen oder Partner informiert?
• Wie wird die Korrektur nachvollziehbar dokumentiert?

Das ist kein technisches Detail. Es ist Teil der Betriebsfähigkeit eines Systems.

Warum Datenbankmigrationen besonders riskant sind

Migrationen liegen genau an der Grenze zwischen Code und Zustand. Sie werden häufig zusammen mit einem Release ausgeliefert, sind aber nicht automatisch reversibel.

Problematisch sind insbesondere Migrationen, die:

• Spalten, Tabellen, Indizes oder Constraints entfernen,
• Werte überschreiben oder zusammenfassen,
• Daten in ein neues Modell überführen und dabei Information verlieren,
• Primärschlüssel oder externe Referenzen verändern,
• Datentypen mit potenziellem Präzisionsverlust ändern,
• große Datenmengen während des Deployments transformieren,
• alte und neue Versionen inkompatibel machen.

Ein down-Skript in einem Migrationstool ist kein Beweis für sichere Reversibilität. Es kann zwar das alte Schema herstellen, aber nicht zwingend die ursprünglichen Daten. Aus full_name wieder first_name und last_name zu machen ist nur dann verlustfrei, wenn die ursprüngliche Struktur tatsächlich erhalten blieb. Aus einer aggregierten Summe lassen sich ihre Einzelwerte nicht rekonstruieren.

Das Muster: Expand, Migrate, Contract

Für kritische Datenbankänderungen hat sich ein mehrstufiges Vorgehen bewährt. Es reduziert die Abhängigkeit von einem perfekten Rollback.

1. Expand

Zuerst wird das Schema nur erweitert: neue Tabellen, neue Spalten, neue Indizes oder zusätzliche Schnittstellen werden eingeführt. Bestehende Leser und Schreiber bleiben funktionsfähig.

Beispiel: Statt eine Spalte customer_id sofort umzubenennen, wird zunächst account_id ergänzt.

2. Migrate

Danach werden Daten kontrolliert übertragen. Je nach Größe und Kritikalität geschieht das als Batch-Prozess, per Backfill, über Event-Replay oder mit zeitlich begrenztem Dual Write.

Wichtig ist die Validierung:

• Stimmen Anzahl und Verteilung der migrierten Datensätze?
• Sind Referenzen vollständig?
• Gibt es fachliche Invarianten, die vor und nach der Migration gelten müssen?
• Wie werden Schreibvorgänge behandelt, die während des Backfills eintreffen?

3. Contract

Erst wenn die neue Struktur über einen ausreichend langen Zeitraum produktiv genutzt und überprüft wurde, wird die alte Struktur entfernt. Dieser Schritt ist bewusst vom eigentlichen Feature-Release getrennt.

Der Vorteil: Ein Code-Rollback bleibt möglich, weil das alte Schema noch vorhanden ist. Der Preis sind temporär höhere Komplexität und eine klarere Migrationsplanung. Das ist in den meisten produktiven Systemen ein guter Tausch.

Externe Zustände lassen sich nicht zurückdeployen

Nicht nur Datenbanken speichern Zustand. Viele Seiteneffekte liegen außerhalb der eigenen Transaktion und häufig außerhalb der eigenen Kontrolle.

Beispiele:

• Eine E-Mail wurde versendet.
• Eine Zahlung wurde autorisiert oder eingezogen.
• Eine Nachricht wurde an einen Message Broker publiziert.
• Ein Dokument wurde in Object Storage abgelegt.
• Ein CRM-System hat einen Kontakt aktualisiert.
• Ein Partner-System hat einen Auftrag angenommen.
• Ein Feature wurde für eine Kundengruppe sichtbar geschaltet.
• Ein KI-Modell hat eine Entscheidung oder Klassifikation erzeugt, die weiterverarbeitet wurde.

Ein Rollback des auslösenden Dienstes macht keines dieser Ereignisse ungeschehen.

Daraus folgen bekannte, aber oft unvollständig umgesetzte Architekturprinzipien:

• Externe Aufrufe müssen idempotent sein oder mit Idempotency Keys abgesichert werden.
• Ereignisse brauchen eindeutige Korrelationen und fachliche Identitäten.
• Kritische Aktionen benötigen Kompensationen, nicht nur technische Retries.
• Der Outbox-Ansatz hilft, Datenänderung und Event-Publikation konsistent zu koppeln.
• Dead-Letter-Queues und Reprocessing-Prozesse brauchen eine fachliche Betriebsanweisung.
• Audit-Daten müssen ausreichend sein, um Entscheidungen und Korrekturen später zu erklären.

Eine Kompensation ist dabei nicht dasselbe wie ein Undo. Eine stornierte Rechnung ist nicht identisch mit einer nie ausgestellten Rechnung. Sie ist ein neuer, nachvollziehbarer Geschäftsvorgang.

Recovery beginnt vor dem Incident

Im Incident ist die Zeit für grundlegende Architekturentscheidungen vorbei. Dann müssen Teams anhand vorbereiteter Informationen entscheiden: Stoppen wir nur das Release? Stellen wir Daten wieder her? Starten wir einen Korrekturprozess? Informieren wir Fachbereiche?

Dafür braucht ein Deployment mindestens eine explizite Einschätzung seiner Zustandsänderungen. Diese Einschätzung gehört in die Release-Vorbereitung, nicht in den Kopf einzelner Personen.

Eine einfache Klassifikation hilft:

Änderung	Beispiel	Rollback ausreichend?	Zusätzliche Maßnahme
Rein stateless	Fehler in einer Berechnung ohne Persistenz	Häufig ja	Monitoring und Verifikation
Reversible Persistenz	Neues optionales Feld wird befüllt	Meist	Korrekturskript oder Schema-Kompatibilität
Irreversible Datenänderung	Alte Werte werden überschrieben oder gelöscht	Nein	Backup, PITR oder validierter Wiederaufbau
Externer Seiteneffekt	E-Mail, Zahlung, Partnerauftrag	Nein	Kompensation und fachlicher Prozess
Sichtbare Geschäftsentscheidung	Preis, Freigabe, Sperrung	Nein	Fachliche Prüfung, Kommunikation, Audit

Die Tabelle ist kein Ersatz für eine Risikoanalyse. Sie zwingt aber dazu, den Unterschied zwischen Softwareversion und Systemzustand sichtbar zu machen.

Checkliste für irreversible Änderungen

Vor einem Release mit potenziell irreversiblen Änderungen sollten diese Fragen konkret beantwortet sein.

Daten und Schema

• Welche Daten werden neu geschrieben, überschrieben, gelöscht oder verdichtet?
• Ist die Migration vorwärts- und rückwärtskompatibel mit den aktuell unterstützten Anwendungsversionen?
• Welche Informationen gehen bei einer Transformation verloren?
• Gibt es ein getestetes Restore-Verfahren, nicht nur ein vorhandenes Backup?
• Wie lange dauert Point-in-Time-Recovery bei der tatsächlichen Datenmenge?
• Ist ein Restore auf eine isolierte Umgebung möglich, um Korrekturskripte zu entwickeln und zu prüfen?
• Welche Validierungen beweisen nach der Migration fachliche und technische Konsistenz?
• Können alte und neue Datenmodelle während einer Übergangsphase parallel betrieben werden?

Externe Systeme und Events

• Welche Nachrichten, Dateien, E-Mails, Zahlungen oder API-Aufrufe kann das Release auslösen?
• Gibt es pro Aktion eine Idempotenzstrategie?
• Ist bekannt, ob der Empfänger eine Stornierung oder Korrektur unterstützt?
• Welche Ereignisse können nach einem Rollback noch verzögert eintreffen?
• Gibt es Korrelationen, mit denen alle betroffenen Vorgänge identifiziert werden können?
• Wer verantwortet die Kompensation technisch und fachlich?

Betrieb und Entscheidung

• Welche Metriken oder Prüfungen erkennen den Fehler früh genug?
• Gibt es einen Kill Switch oder ein Feature Flag, das die Wirkung ohne neues Deployment begrenzt?
• Welche konkrete Bedingung löst einen Rollback aus?
• Welche Bedingung verlangt stattdessen einen Stopp und eine Recovery-Entscheidung?
• Wer darf Datenkorrekturen oder fachliche Stornierungen freigeben?
• Ist die Reihenfolge dokumentiert: Traffic stoppen, Jobs pausieren, Consumer anhalten, Daten sichern, analysieren, korrigieren, wieder freigeben?
• Wurde der Ablauf unter realistischen Bedingungen geübt?

Backups sind notwendig, aber keine vollständige Antwort

Backups werden gerne als universelle Absicherung genannt. In verteilten Systemen lösen sie aber nur einen Teil des Problems.

Ein Datenbank-Restore auf einen früheren Zeitpunkt kann neue Daten verlieren, die nach diesem Zeitpunkt korrekt entstanden sind. Er stellt auch keine Zustände in Payment-Providern, SaaS-Systemen oder Kund:innen-Postfächern wieder her. Je länger ein Fehler unentdeckt bleibt, desto schwieriger wird ein pauschaler Restore.

Deshalb ist ein gezieltes Korrekturverfahren oft sicherer als ein vollständiger Restore. Dafür müssen betroffene Entitäten eindeutig ermittelbar sein. Ein Release sollte idealerweise nachvollziehbar machen können:

• welche Version eine Änderung ausgelöst hat,
• wann sie ausgeführt wurde,
• welche Datensätze und externen Aktionen betroffen sind,
• mit welcher Korrelation ein Vorgang zusammenhängt.

Ohne diese Informationen wird Recovery schnell zur forensischen Arbeit in Logs, Datenbanken und Tickets.

Was ich in Architektur-Reviews sehen möchte

Bei risikoreichen Änderungen reicht mir kein Satz wie „Wir können bei Problemen zurückrollen“. Ich erwarte eine präzisere Antwort:

1. Was verändert dieses Release dauerhaft?
2. Welche dieser Veränderungen sind technisch reversibel, welche nur fachlich kompensierbar?
3. Wie erkennen wir den Fehler, bevor die Wirkung zu groß wird?
4. Wie begrenzen wir den Blast Radius?
5. Wie sieht der konkrete Recovery-Ablauf aus, einschließlich Verantwortlichkeiten und Validierung?

Diese Fragen sind besonders wichtig bei Datenmigrationen, Integrationen, Batch-Jobs, Berechtigungsmodellen und Abrechnungsprozessen. Gerade dort ist die Differenz zwischen einem grünen Deployment und einem korrekten Geschäftszustand groß.

Fazit

Ein Rollback ist ein wichtiges Werkzeug, aber kein allgemeiner Rückgängig-Knopf. Es stellt normalerweise eine frühere Code- oder Konfigurationsversion wieder her. Daten, Nachrichten, externe Systeme und fachliche Folgen bleiben davon unberührt.

Zuverlässige Systeme planen deshalb drei getrennte Fähigkeiten: schnellen Code-Rollback, belastbare Daten-Recovery und fachlich verantwortete Business-Recovery. Wer irreversible Änderungen sichtbar macht, Migrationen schrittweise aufbaut und Kompensationen vorbereitet, verkürzt Incidents nicht nur technisch. Er reduziert vor allem das Risiko, dass ein vermeintlich erfolgreicher Rollback einen fehlerhaften Zustand verdeckt.