Eine Löschanfrage ist nicht mit einem DELETE auf der Benutzertabelle erledigt. In einer Anwendung mit mehreren Modulen können Informationen in verknüpften Datensätzen, Dateien, Suchindizes, Warteschlangen, Exporten oder externen Diensten vorkommen. Wird nur das sichtbare Konto gelöscht, können weiterhin zugängliche Kopien zurückbleiben; blindes Löschen kann Daten betreffen, die erhalten bleiben müssen, damit andere Prozesse weiter funktionieren.
Eine überprüfbare Datenlöschung in PHP wird als Prozess mit explizitem Umfang, Verantwortlichen, Statuswerten, Wiederholungsversuchen und Prüfungen entworfen. Das operative Ziel besteht nicht darin, zu versprechen, dass jede Kopie sofort verschwindet. Vielmehr soll nachvollziehbar sein, welche Ziele verarbeitet wurden, welches Ergebnis jeweils erzielt wurde und welche Einschränkungen noch bestehen.
Den Umfang vor der Ausführung festlegen
Übertragen Sie die Anfrage in ein Verzeichnis der Datenkategorien und Systeme. Ein Konto kann beispielsweise ein Profil, Einstellungen, Sitzungen, Dokumente, Kommentare und Aktivitätsereignisse umfassen. Außerdem können Referenzen in Rechnungen oder anderen gemeinsam genutzten Datensätzen vorhanden sein. Entscheiden Sie für jede Kategorie, ob sie gelöscht, entkoppelt, anonymisiert oder gemäß einer anwendbaren internen Richtlinie aufbewahrt werden soll. Behandeln Sie diese Optionen nicht als gleichwertig: Bei einer Anonymisierung muss die Person im vorgesehenen Kontext nicht mehr identifizierbar sein, und durch Entkoppeln werden die ursprünglichen Daten nicht notwendigerweise gelöscht.
Legen Sie außerdem fest, was für jedes Ziel als „abgeschlossen“ gilt. Eine aus der Hauptdatenbank entfernte Zeile belegt nicht, dass der Suchindex aktualisiert oder eine Datei gelöscht wurde. Unterscheiden Sie zwischen Zielen unter direkter Kontrolle – Datenbank, Objektspeicher, Cache – und Zielen, die von einem Anbieter oder einem Aufbewahrungszeitraum abhängen, etwa bestimmten Backups. Der Endstatus sollte diese Unterschiede widerspiegeln, statt sie unter einem einzigen Erfolgsstatus zu verbergen.
Kopien erfassen und Verantwortliche benennen
Das Verzeichnis muss den tatsächlichen Datenflüssen folgen, nicht nur dem Datenbankschema. Prüfen Sie, wo Daten erstellt, exportiert oder umgewandelt werden: Job-Warteschlangen, Suchindizes, Analysesysteme, temporäre Dateien, Anwendungsprotokolle und angebundene Tools. Fragen Sie jedes Team, mit welchem Bezeichner sich Datensätze finden lassen und welche Operation das jeweilige System unterstützt.
Benennen Sie für jedes Ziel eine technische verantwortliche Person und dokumentieren Sie den Mechanismus, die erwartete Antwort, Wiederholungsversuche und Einschränkungen. Wenn sich in einem System nicht anhand eines stabilen Bezeichners suchen lässt, erschwert dieser Mangel die Überprüfung und sollte als technische Schuld behandelt werden. Vermeiden Sie es, im Anfragendatensatz selbst eine zusätzliche Kopie personenbezogener Daten zu speichern: In der Regel genügen eine interne Fall-ID, die für die Durchführung erforderliche Referenz und minimierte Ergebnisse.
Status und Ergebnisse je System modellieren
Ein robuster Prozess verfügt über explizite Statuswerte, zum Beispiel: received, validated, in_progress, partially_completed, verification_pending, completed und failed. Legen Sie die Übergänge und die jeweils dazu berechtigten Personen fest. Eine Anfrage sollte nicht als abgeschlossen markiert werden, solange für obligatorische Ziele kein überprüfbares Ergebnis vorliegt.
Erfassen Sie das Ergebnis für jedes System separat: ausstehend, gelöscht, nicht gefunden, erneut versuchbar, prüfungsbedürftig oder einer dokumentierten Einschränkung unterliegend. „Nicht gefunden“ kann ein gültiges Ergebnis sein, aber nur, wenn die Abfrage den richtigen Schlüssel verwendet und den vorgesehenen Umfang abgedeckt hat. Unterscheiden Sie einen vorübergehenden Fehler – zum Beispiel einen nicht verfügbaren Dienst – von einer dauerhaften Ablehnung, die ein Eingreifen erfordert.
Trennen Sie in PHP die Koordination von der zielsystemspezifischen Arbeit. Ein Anwendungsdienst kann den Fall laden, Berechtigungen prüfen und Aufgaben versenden; unabhängige Adapter implementieren Operationen für Datenbank, Speicher oder APIs. So zwingt eine Änderung bei einem Anbieter nicht dazu, Geschäftslogik mit Transportdetails zu vermischen. Sichern Sie außerdem das Anlegen und Abrufen des Falls durch Zugriffskontrollen ab und protokollieren Sie, wer administrative Aktionen gestartet hat.
Die Löschung unter Berücksichtigung von Abhängigkeiten ordnen
Ermitteln Sie vor dem Löschen, welche Beziehungen vom Konto abhängen und welche gemeinsam genutzt werden. Fremdschlüssel und Kaskadenregeln für Löschvorgänge tragen zur Wahrung der Integrität bei, doch eine Kaskade kann mehr als beabsichtigt löschen, wenn das Modell eigene und gemeinsam genutzte Daten vermischt. Prüfen Sie die Auswirkungen jeder Beziehung und bevorzugen Sie explizite Operationen, wenn der Umfang nicht eindeutig ist.
Eine übliche Reihenfolge besteht darin, neue Schreibvorgänge für das betreffende Subjekt zu stoppen, Sitzungen oder Zugangsdaten ungültig zu machen, interne Abhängigkeiten zu entfernen, eigene Datensätze zu löschen oder umzuwandeln und anschließend die Operation an Indizes und externe Dienste weiterzugeben. Die konkrete Reihenfolge hängt von der Architektur ab. Wird zuerst der Schlüssel gelöscht, mit dem sich Daten in anderen Systemen finden lassen, kann dem Auftrag die für die Fortsetzung erforderliche Information fehlen. Bewahren Sie diese Arbeitsreferenz geschützt und nur so lange wie nötig auf, ohne den operativen Datensatz in einen parallelen Datenspeicher zu verwandeln.
Den Prozess idempotent und fortsetzbar gestalten
Verteilte Jobs können scheitern, nachdem eine Operation abgeschlossen, aber bevor dies gemeldet wurde. Daher muss jeder Schritt wiederholt werden können, ohne unerwünschte Auswirkungen zu verursachen. Bei einer idempotenten Löschung kann akzeptiert werden, dass ein Datensatz bereits nicht mehr existiert, und ein kontrolliertes Ergebnis zurückgegeben werden, statt dies stets als Fehler zu behandeln.
Speichern Sie den Fortschritt für jedes Ziel und verwenden Sie einen Idempotenzschlüssel oder eine stabile Fall-ID, sofern das entfernte System dies unterstützt. Verarbeiten Sie jedes Ziel in einer geeigneten Transaktion oder Arbeitseinheit, ohne eine Datenbanktransaktion offenzuhalten, während Sie auf eine API warten. Kommt es zu einem Fehler, versuchen Sie es mit Begrenzungen und einer Wartezeitstrategie erneut; ausgeschöpfte Fehler müssen in eine Prüfwarteschlange überführt werden, statt in einem Log zu verschwinden.
Bei der Fortsetzung soll der Prozess an den unvollständigen Schritten wiederaufnehmen. Starten Sie nicht den gesamten Ablauf neu, wenn dadurch unsichere Aktionen wiederholt oder vorherige Ergebnisse überschrieben werden könnten. Unterscheiden Sie insbesondere zwischen „Anfrage gesendet“ und „Löschung bestätigt“: Eine erfolgreiche HTTP-Antwort kann den Empfang bestätigen, nicht unbedingt den Abschluss des entfernten Auftrags. Klären Sie mit dem Anbieter die Bedeutung jeder Bestätigung.
Prüfen, ohne die zu löschenden Daten aufzubewahren
Die Überprüfung muss zum Ziel und zur Art der Operation passen. In der Datenbank kann eine Abfrage anhand der vorgesehenen Schlüssel bestätigen, dass im festgelegten Umfang keine Zeilen mehr vorhanden sind. Im Speicher lässt sich die Abwesenheit des Objekts oder die Antwort des Löschmechanismus prüfen. Bei einem Index muss das Dokument anhand eines geeigneten Schlüssels abgefragt und die Weitergabedauer berücksichtigt werden. Eine Erfolgsmeldung des Workers ersetzt diese Prüfungen nicht.
Erfassen Sie minimale Nachweise: Fall-ID, Ziel, Operation, Zeitstempel, Status, Anzahl betroffener Elemente, sofern dies unbedenklich ist, und eine technische Referenz des Ergebnisses. Vermeiden Sie es, gelöschte Inhalte, Zugangsdaten, Tokens oder unnötige personenbezogene Bezeichner in Logs und Metriken zu kopieren. Schützen Sie das Auditprotokoll, beschränken Sie den Zugriff darauf und legen Sie dessen interne Aufbewahrungsdauer fest. Die Nachweise sollen es ermöglichen, den Prozess zu erläutern, ohne die Informationen wiederherzustellen, die entfernt werden sollten.
Einschränkungen verwalten und den Ablauf testen
Backups erfordern eine explizite Behandlung. Eine selektive sofortige Löschung ist dort möglicherweise nicht möglich; dokumentieren Sie den vorgesehenen Aufbewahrungszyklus und wie verhindert wird, dass eine Wiederherstellung bereits gelöschte Daten erneut einführt. Beispielsweise kann das Wiederherstellungsverfahren ausstehende oder abgeschlossene Anfragen erneut anwenden, bevor das wiederhergestellte System freigegeben wird. Behaupten Sie nicht, ein Backup sei gelöscht worden, wenn der verfügbare Mechanismus lediglich vorsieht, dass es gemäß seiner Aufbewahrungsfrist abläuft.
Geben Sie für externe Systeme an, wer die Operation starten darf, welche Bestätigung der Anbieter liefert und wann ein ungewisses Ergebnis eskaliert werden muss. Eine operative Einschränkung ist keine erfolgreiche Überprüfung: Je nach verfügbarer Evidenz muss sie als ausstehend, eingeschränkt oder geklärt ausgewiesen werden.
Testen Sie den Ablauf vor dem Betrieb in Nicht-Produktionsumgebungen mit synthetischen Daten: doppelte Anfragen, gemeinsam genutzte Beziehungen, fehlende Dateien, Timeouts, mehrdeutige Antworten und Fehler nach Abschluss eines Schritts. Prüfen Sie, dass Wiederholungsversuche keine Auswirkungen duplizieren, Berechtigungen unzulässige Zugriffe blockieren und Berichte keine Daten offenlegen. Überwachen Sie in der Produktion die Fehlerhäufigkeit, das Alter ausstehender Fälle und Ziele ohne Bestätigung, ohne personenbezogene Informationen in Warnmeldungen aufzunehmen.
Checkliste: Umfang und Ausnahmen festgelegt; Ziele und Verantwortliche erfasst; Statuswerte und Übergänge dokumentiert; Abhängigkeiten geprüft; Schritte idempotent und fortsetzbar; systembezogene Überprüfung; minimierte und geschützte Nachweise; Einschränkungen von Backups und Anbietern kommuniziert; Fehlerszenarien getestet; Prüf- und Eskalationsverfahren verfügbar. Mit diesen Kontrollen kann das Team nachvollziehbar reagieren und genau erkennen, an welcher Stelle eine Löschung angehalten wurde, statt eine eingeleitete Aktion mit einem bestätigten Ergebnis zu verwechseln.
