DSGVO-Cascade-Löschung — „lösch mich" verschwindet wirklich
Wenn eine Nutzerin Löschung verlangt, wird ihr Datensatz nicht „aus der Sicht der App" verborgen, sondern kaskadierend aus jeder abhängigen Stelle gestrichen — App-Datenbanken, Event-Ledger, abgeleitete Caches, Backups in Rotation, Logs.
„Lösch mich” ist eine der einfachsten Forderungen einer Nutzerin und gleichzeitig eine der technisch teuersten, wenn man sie ernst nimmt. Viele Anbieter lösen sie kosmetisch: das Konto verschwindet aus der UI, der Datensatz bleibt aber in der Datenbank, in Analytics-Pipelines, in Backups, in Logs. Aus Sicht der Nutzerin ist sie weg; aus Sicht der Datenflüsse nicht.
Wir haben uns festgelegt, dass eine Löschung kaskadieren muss. Eine
Lösch-Anfrage erzeugt ein Tombstone-Event im zentralen Event-
Ledger. Alle Apps konsumieren dieses Event und entfernen ihre
zugehörigen Projektionen. Der mana-admin-Service koordiniert,
über welche Apps der Datensatz verteilt war, und macht den Lauf
auditierbar. Backups rotieren mit dokumentierter Latenz mit — wir
können nicht verhindern, dass ein gestern erstelltes Backup für
ein paar Tage existiert, aber wir können sicherstellen, dass es
nach Ablauf der Rotations-Frist nicht mehr neu hervorgeholt wird.
Diese Mechanik kostet uns einiges. Jede neue App, die der Verein hostet, muss vor dem Live-Schalten ihre Tabellen für die GDPR- Manifestation deklarieren; sonst kann sie nicht in den Lösch-Lauf aufgenommen werden. Föderierte Inhalte sind ein Sonderfall — ein Beitrag zur Allmende kann nicht beliebig zurückgezogen werden, ohne die Allmende zu zerstören. Diese Spannungen lösen wir nicht mit Marketing-Floskeln, sondern mit Regeln in der Datenschutzerklärung: was kaskadiert, was nicht, in welcher Frist.
Wie genau das funktioniert
- Eine Lösch-Anfrage erzeugt ein Tombstone-Event im `sync2`- Ledger. Alle Projektionen verarbeiten es und entfernen abhängige Datensätze.
- Plattform-Service `mana-admin` koordiniert Cross-Service- Löschung über alle Apps, die der Nutzerin Daten zuordnen.
- Alle Apps erklären in einer Manifestation (GDPR_PRODUCTS-Env), welche Tabellen sie pro User halten — der Lösch-Lauf gegen diese Manifestation ist auditierbar.
- Backups werden mit kalkulierter Rotations-Frist mitgelöscht; die maximale Latenz vom Lösch-Auftrag bis zur tatsächlichen Backup-Vergessenheit ist in der Datenschutzerklärung benannt.
- Log-Aufbewahrung minimal; personenbezogene Felder werden server-seitig nicht in Logs geschrieben.
Was uns das kostet
Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.
- Cross-Service-Löschung kann fehlschlagen, wenn ein Service offline ist. Das System retried; in der Zwischenzeit muss die UI ehrlich sagen, dass die Löschung noch nicht durch ist.
- Backups haben eine Rotations-Latenz, die wir nicht beliebig kurz machen können. Das ist nicht zu verbergen, sondern offen zu benennen.
- Geteilte Inhalte (Föderation, gemeinsame Korpora) brauchen Sonder-Regeln — der eigene Beitrag wird gelöscht, das geteilte Ergebnis kann es nicht mehr vollständig.
Welche Probleme dieser Lösung adressiert
Diagnose ohne Antwort ist Lamentation; Antwort ohne Diagnose ist Ingenieurs-Spielerei. Hier verbindet sich beides.
Welche Grundsätze er trägt
Offene Punkte
- Audit-Kanzlei-Review der konkreten Lösch-Routinen steht aus (gemeinsamer Audit für 11 Apps).
- Backup-Off-Site-Strategie nicht final — solange die Backups nur lokal sind, ist auch der Off-Site-Löschpfad nicht definiert.
Weitere Lösungen dieser Art
Wie Geräte und Apps sich verständigen.
Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.