Event Sourcing für CRUD

Wir haben Event Sourcing für eine einfache CRUD-App umgesetzt, weil „das der richtige Weg ist“. 6 Monate für Infrastruktur statt für Features verbraucht.

Die Anforderungen der App:

• Nutzerverwaltung per CRUD
• 500 tägliche Nutzer
• Keine Audit-Anforderungen
• Kein Time-Travel nötig
• Standard-Geschäftslogik

Was wir gebaut haben:

• Event Store auf Kafka + PostgreSQL — für sich schon eine fragwürdige Entscheidung: Kafka als Event Store bietet keine Reads pro Aggregat und eine sperrige Retention-Semantik, was uns zusätzliche Workarounds kostete
• Event-Replay-System
• Projektionen (Read Models)
• Snapshotting
• Versionierte Events
• Saga-Orchestrierung

Zeitaufwand:

• Infrastruktur: 4 Monate
• Event-Schema-Design: 1 Monat
• Debugging von Eventual Consistency: 1 Monat
• Tatsächliche Business-Features: 2 Wochen

Der Consistency-Debugging-Monat an einem Beispiel: Ein Nutzer änderte seine E-Mail-Adresse, der Bestätigungsbildschirm zeigte noch die alte, weil das Read Model hinterherhinkte, er versuchte es erneut — und wir verbrachten zwei Tage damit, doppelte EmailChanged-Events durch einen Projection-Rebuild zu verfolgen. Für ein Formular, das eine Zeile aktualisiert.

Was wir gebraucht hätten:

class User:
    def update(self, data):
        self.name = data.name
        self.email = data.email
        db.save(self)

Wann Event Sourcing sinnvoll ist:

• Regulatorische Audit-Trail-Anforderungen
• Finanztransaktionen
• Time-Travel-Debugging
• Komplexe Domäne mit vielen Zustandsübergängen

Lektion: Event Sourcing ist mächtig. Es ist auch teuer. Passen Sie die Komplexität an die Anforderungen an — es ist derselbe Instinkt, der kleine Teams in Microservices treibt, die sie nicht brauchen.

---

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers auf dem Pager — damit Geschichten wie diese im Archiv bleiben.