CQRS eventual consistency Flashcards
What does CQRS stand for?
Command Query Responsibility Segregation – A pattern separating read (query) and write (command) models.
How does CQRS differ from CRUD?
CRUD: Single model for Create, Read, Update, Delete.
CQRS: Separate models for Commands (writes) and Queries (reads).
What is the main benefit of CQRS?
Simplified models (optimized for reads vs. writes).
Independent scaling of read/write workloads.
Better alignment with complex domains or high-performance systems.
When is CQRS not recommended?
For simple CRUD-based systems, as it adds unnecessary complexity.
How do the command and query models communicate in CQRS?
Same database (shared storage).
Separate databases (e.g., ReportingDatabase) with event-driven updates or messaging.
What architectural patterns pair well with CQRS?
Event Sourcing (stores state changes as events).
Event Collaboration (services communicate via events).
Domain-Driven Design (DDD) (especially Bounded Contexts).
What is eventual consistency in CQRS?
The query model may lag behind the command model temporarily (due to async updates).
In CQRS, how can read models optimize performance?
EagerReadDerivation (pre-compute data).
MemoryImages (keep read models in memory).
ReportingDatabase (offload complex queries).
Should CQRS be applied to an entire system?
No – Only to specific Bounded Contexts (DDD) where the benefits outweigh complexity.
What’s a ReportingDatabase, and how does it differ from CQRS?
ReportingDatabase: Offloads only complex queries (keeps main model for most operations).
CQRS: Fully separates read and write models.
What’s a key risk of using CQRS?
Added complexity (harder to maintain, requires skilled team, and can reduce productivity if misapplied).
What type of UI fits well with CQRS?
Task-based UI (e.g., “Cancel Order” vs. generic “Save” in CRUD).
What is the core principle of CQRS?
Separating read (query) and write (command) operations into distinct models for optimization.
What are the key challenges in traditional CRUD architectures that CQRS addresses?
Data mismatch (different read/write representations).
Lock contention (parallel operations).
Performance issues (complex queries, high load).
Security challenges (overlapping permissions).
How does CQRS improve performance?
Independent scaling of read/write workloads.
Optimized schemas (denormalized reads, transactional writes).
Simpler queries (materialized views avoid joins).
What are the two approaches to implementing CQRS?
Single data store (separate logic for reads/writes).
Separate data stores (different databases, synchronized via events)
What is eventual consistency in CQRS?
Read models may lag behind write models temporarily (async updates).
When is CQRS most beneficial?
High read-to-write ratios.
Complex domains (e.g., DDD, task-based UIs).
Collaborative environments (minimizes merge conflicts).
What is a key trade-off of CQRS?
Increased complexity (harder to design/maintain vs. CRUD).
How does CQRS enhance security?
By isolating write permissions (commands) from read-only queries.
What pattern is commonly combined with CQRS, and why?
Event Sourcing (stores state changes as events; simplifies read model generation).
What is a materialized view in CQRS?
A precomputed snapshot of data (optimized for fast reads, avoids joins).
When should you avoid CQRS?
For simple CRUD apps (overkill) or when strong consistency is critical.
How does CQRS support scalability?
Horizontal scaling of read models.
Low-contention writes (fewer instances).
What is the role of messaging in CQRS?
Handles async command processing and event propagation (e.g., via queues).
What is idempotent message processing in CQRS?
Ensuring duplicate messages (e.g., retries) don’t corrupt data.
How does CQRS align with Domain-Driven Design (DDD)?
Commands map to business tasks (e.g., “Book room” vs. “Update status”).
Bounded Contexts define CQRS boundaries.
