Eine Architekturentscheidung mit langfristigen Folgen

Das Löschen von Daten wirkt auf den ersten Blick trivial. Ein Datensatz wird entfernt und das Problem ist erledigt.

In der Praxis ist die Entscheidung zwischen Soft Delete und Hard Delete jedoch eine derjenigen, die langfristig die Komplexität eines Systems stark beeinflusst.

Was ist der Unterschied?

Beim Hard Delete wird ein Datensatz physisch aus der Datenbank entfernt.

Beim Soft Delete bleibt der Datensatz erhalten und wird stattdessen als gelöscht markiert, typischerweise durch ein Feld wie deleted_at oder is_deleted.

Beide Ansätze lösen das gleiche Problem auf unterschiedliche Weise, mit sehr unterschiedlichen Konsequenzen.

Hard Delete: Einfach, aber endgültig

Hard Deletes sind technisch unkompliziert.

• Keine zusätzlichen Bedingungen in Queries
• Keine versteckten Datensätze
• Klare Datenbasis

Der Preis dafür ist der Verlust von Information.

• Keine Wiederherstellung möglich
• Keine Historie
• Referenzen können brechen

Hard Deletes sind dann sinnvoll, wenn Daten wirklich keine Bedeutung mehr haben oder bewusst entfernt werden müssen.

Soft Delete: Flexibel, aber komplex

Soft Deletes bieten mehr Kontrolle über Daten, führen aber zu zusätzlicher Komplexität.

• Daten können wiederhergestellt werden
• Historie bleibt erhalten
• Referenzen bleiben konsistent

Diese Vorteile kommen mit klaren Nachteilen:

• Jede Query muss den Löschstatus berücksichtigen
• Fehler durch „vergessene Filter“ sind häufig
• Daten wachsen kontinuierlich weiter

Das System wirkt stabil, wird aber mit der Zeit schwerer zu kontrollieren.

Der häufigste Fehler: Soft Delete ohne Strategie

In vielen Systemen wird Soft Delete eingeführt, ohne die langfristigen Konsequenzen zu berücksichtigen.

Typische Probleme:

• Inkonsistente Filterlogik über verschiedene Services hinweg
• „Gelöschte“ Daten tauchen unerwartet wieder auf
• Unklare Regeln, wann Daten endgültig entfernt werden

Das führt dazu, dass das System zwei Zustände verwalten muss: sichtbar und unsichtbar, ohne klare Trennung.

Technische Auswirkungen im Detail

Queries:
Soft Deletes erfordern zusätzliche Bedingungen in fast jeder Abfrage. Das erhöht die Komplexität und kann Performance beeinflussen.

Indizes:
Indizes müssen oft den Löschstatus berücksichtigen, was ihre Effektivität verändern kann.

Constraints:
Unique Constraints funktionieren nicht mehr wie erwartet, da „gelöschte“ Daten weiterhin existieren.

Referenzen:
Foreign Keys bleiben bestehen, was einerseits hilfreich ist, andererseits unerwartete Abhängigkeiten verlängert.

Wann welcher Ansatz sinnvoll ist

Hard Delete eignet sich, wenn:

• Daten keine langfristige Bedeutung haben
• Speicher und Klarheit wichtiger sind als Historie
• rechtliche Anforderungen Löschung erzwingen

Soft Delete eignet sich, wenn:

• Daten wiederherstellbar sein müssen
• Auditing oder Historie wichtig ist
• Beziehungen zwischen Daten erhalten bleiben sollen

Best Practices aus der Praxis

• Klare Konvention für Löschfelder definieren (z. B. deleted_at statt Boolean)
• Zentrale Query-Filter verwenden (z. B. Repository-Layer)
• Strategie für endgültige Löschung festlegen (z. B. Cleanup-Jobs)
• Soft Deletes nicht als Default verwenden, sondern bewusst entscheiden

Fazit

Die Entscheidung zwischen Soft Delete und Hard Delete ist keine Implementierungsfrage, sondern eine Architekturentscheidung.

Hard Delete reduziert Komplexität, verliert aber Information.

Soft Delete erhält Information, erhöht aber systemweite Komplexität.

Die richtige Wahl hängt nicht von technischer Präferenz ab, sondern davon, welche Kosten man langfristig tragen möchte.