Event-Sourcing als Daten-Architektur

Die meisten Apps speichern den aktuellen Zustand in einer Datenbank und überschreiben ihn, wenn sich etwas ändert. Das ist einfach, schnell und schmerzlos — bis jemand fragt: „Wer hat das wann geändert?” oder „Was hat die KI da gerade entschieden?” oder „Lösch alles über mich, restlos.” Mit mutiertem State sind diese Fragen entweder gar nicht oder nur mit nachträglich aufgesetzten Audit-Logs zu beantworten, die ihrerseits eine weitere Datenquelle sind, die mit der Wahrheit synchron bleiben muss.

Wir haben uns Mitte 2026 entschieden, das umgekehrt zu bauen. Statt die aktuelle Welt in der Datenbank zu pflegen, schreiben unsere Apps jede Änderung als unveränderliches Event in einen zentralen Ledger (sync2). Die App-Datenbanken sind dann nichts weiter als Projektionen — sekundäre, neu aufbaubare Sichten auf die Event-Geschichte. Wenn wir uns vertippen, regenerieren wir die Projektion; die Wahrheit bleibt erhalten.

Aus dieser Entscheidung fallen Dinge ab, die wir sonst hätten einzeln einbauen müssen. Eine Cross-App-Timeline („was hat sich in allen meinen Apps in den letzten 24 Stunden geändert, inklusive KI-Aktionen?”) ist ein triviales Read-Modell, kein neues System. DSGVO-Lösch-Kaskaden funktionieren, weil wir alle Events einer Nutzerin in der Datenbank finden können. Zero-Knowledge wird einfach: die sensiblen Felder im Event werden client-seitig verschlüsselt, der Server sieht nur Chiffretext. KI-Aktionen werden zu eigenen, attribuierten Events — sichtbar, widerrufbar, nicht stillschweigend in den User-State gemischt.

Das hat einen Preis. Event-Sourcing ist anspruchsvoller zu bauen und zu warten als ein klassischer CRUD-Server, der Speicher wächst, und Schema-Migrationen sind teurer. Wir zahlen diese Komplexität bewusst — nicht weil sie elegant ist, sondern weil sie strukturelle Eigenschaften erzwingt, die wir mit nachgelagerten Tricks nicht mehr glaubwürdig einbauen könnten.