CQRS (Command Query Responsibility Segregation) ist ein Architekturmuster, das Schreiboperationen (Commands) und Leseoperationen (Queries) in getrennte Modelle auftrennt. Statt eines einzigen Datenmodells für beide Zwecke besitzt das System ein optimiertes Schreibmodell und ein oder mehrere speziell auf Abfragen zugeschnittene Lesemodelle.
Grundidee
Klassische Anwendungen nutzen ein gemeinsames Modell für Lesen und Schreiben. Bei hoher Last oder komplexen Fachregeln wird das zum Engpass: Abfragen brauchen andere Strukturen (denormalisiert, aggregiert) als Schreibvorgänge (validiert, fachlich konsistent). CQRS trennt deshalb beides — Commands sind aufgabenorientiert („Zimmer buchen“ statt „Status auf Reserviert setzen“), Queries liefern reine Datenübertragungsobjekte ohne Fachlogik.
Vorteile
- Getrennte Skalierung: Lesemodelle lassen sich unabhängig vom Schreibpfad skalieren und cachen.
- Fein abgestimmte Performance: Queries laufen gegen optimierte, denormalisierte Sichten (Materialized Views).
- Klare Fachmodelle: Das Schreibmodell kann komplexe Validierungen und Aggregat-Regeln kapseln.
Herausforderungen
- Eventual Consistency: Lesemodelle hinken dem Schreibmodell hinterher.
- Komplexität: Zwei Modelle, Synchronisationslogik und mehr Infrastruktur statt einer einfachen CRUD-Schicht.
- Aufwand: Sinnvoll vor allem bei hohen Anforderungen an Skalierung, parallele Zugriffe oder komplexe Domänen — nicht für einfache Anwendungen.
CQRS wird oft mit Event Sourcing kombiniert: Der Ereignisstrom speist die Lesemodelle. Gegenüber einem klassischen Monolithen mit einer Datenbank ist CQRS typisch für Microservice-Architekturen, die über eventual consistency verbunden sind; Ereignisse werden zuverlässig über eine Transactional Outbox veröffentlicht.
Verwandte Grundlagen: CAP-Theorem, Saga-Muster.