Zum Hauptinhalt springen

Data Projection (Read Models)

Einleitung​

Data Projections erzeugen aus Transaktionsdaten oder Ereignissen leseoptimierte Sichten.

Sie entkoppeln:

  • das konsistenzfokussierte Write-Modell
  • von den performance- und UX-getriebenen Query-Anforderungen

Projections sind zentral in CQRS-Architekturen –
aber auch unabhängig davon ein wichtiges Skalierungs- und Modellierungsinstrument.

Einordnung

Data Projection ist ein Meso-Pattern für query-seitige Optimierung.

Es gehört zur:

  • Lese-Ebene eines Systems
  • Performance-Optimierung
  • UX-Optimierung
  • Reporting-Architektur

Es ist kein vollständiger Architekturstil, sondern ein Baustein.

Grundprinzip

Kernaussage:

  • Writes optimieren Konsistenz
  • Projections optimieren Abfrage
  • Synchronisation ist meist asynchron

Charakteristika

1️⃣ Use-Case-spezifische Read Models​

Ein Projection-Modell ist:

  • nicht generisch
  • nicht normalisiert
  • nicht „schön“ im DDD-Sinne

Es ist optimiert für:

  • konkrete Screens
  • Reports
  • APIs
  • Suchanfragen

2️⃣ Denormalisierung ist erlaubt​

Projections dürfen:

  • redundante Daten enthalten
  • vorberechnete Aggregationen speichern
  • flache Strukturen nutzen

Performance schlägt Modellreinheit.

3️⃣ Asynchrone Aktualisierung​

Typisch über:

  • Domain Events
  • Outbox Pattern
  • Change Data Capture (CDC)
  • Streaming (Kafka, Pulsar etc.)

Das führt meist zu:

eventual consistency.

4️⃣ Rebuild-Fähigkeit​

Eine Projection sollte:

  • neu berechenbar sein
  • versionierbar sein
  • isoliert deploybar sein

Rebuild ist kein Sonderfall – es ist Teil des Designs.

Varianten

🟢 Synchronous Projection​

  • Aktualisierung innerhalb derselben Transaktion
  • Keine Eventual Consistency
  • Geringere Komplexität

🟡 Asynchronous Projection​

  • Event-getrieben
  • Höhere Skalierbarkeit
  • Eventual Consistency

🔵 Streaming-basierte Projection​

  • Kontinuierliche Verarbeitung
  • Near-Real-Time Updates
  • Hohe Infrastruktur-Anforderungen

Vorteile

  • Sehr hohe Query-Performance
  • Geringe Latenz für UI
  • Entkopplung von Write-Komplexität
  • Skalierbare Read-Seite
  • Gute Reporting-Fähigkeit

Risiken / typische Fallstricke

1️⃣ Eventual Consistency nicht erklärt​

Fachbereiche müssen verstehen:

  • Daten sind nicht sofort konsistent.

2️⃣ Leise Inkonsistenzen​

Fehler in Projection-Logik erzeugen:

  • stille Datenfehler
  • schwer erkennbare Drift

Monitoring ist Pflicht.

3️⃣ Rebuild-Kosten​

Große Event-Historien:

  • machen Reprocessing teuer
  • benötigen Partitionierung oder Snapshots

4️⃣ Verwechslung mit Cache​

Eine Projection ist:

  • dauerhaft
  • fachlich relevant
  • rebuildbar

Ein Cache ist:

  • temporär
  • performance-getrieben
  • ersetzbar

Wann sinnvoll?

  • Viele unterschiedliche Query-Use-Cases
  • Read-Last dominiert
  • Komplexe Write-Logik
  • Reporting- oder Analytics-Bedarf

Wann unnötig?

  • Wenige, einfache Abfragen
  • Strikte sofortige Konsistenz erforderlich
  • Geringe Last

Strategische Perspektive

Data Projections sind:

  • ein Skalierungsinstrument
  • ein UX-Optimierungsinstrument
  • ein Entkopplungsmechanismus

Sie verschieben Komplexität von:

„komplexe Abfragen im Write-Store“

zu:

„kontrollierte Modell-Duplizierung im Read-Store“.

Fazit

Data Projection trennt:

  • Konsistenzlogik
  • von Abfrageoptimierung

Sie ist besonders wertvoll in:

  • CQRS
  • Event-getriebenen Systemen
  • Reporting-intensiven Plattformen

Sie ist kein Muss – aber ein sehr starkes Werkzeug bei wachsenden Systemen.