Patterns
35 items
35 items
Separating read and write models for scalability
Command Query Responsibility Segregation (CQRS) separates read (query) and write (command) operations into different models. Commands mutate state through a write model optimized for consistency. Queries read from read models optimized for specific access patterns. This separation enables massive read scalability and complex queries without impacting writes.
Most applications have vastly different read and write patterns. Writes are infrequent and require strong consistency. Reads are frequent and have diverse access patterns. A single model optimized for one pattern compromises the other.
The write model focuses on enforcing business invariants, validating commands, and maintaining consistency. It uses normalized schemas and transactions.
Read models are optimized for specific queries. You can have multiple read models: one denormalized for dashboards, one in Elasticsearch for search, one in Redis for real-time updates.
Traditional applications use a single model for both reads and writes. This forces compromises that hurt both operations. Write optimization (normalization) hurts read performance. Read optimization (denormalization) complicates writes.
CQRS exists on a spectrum. Simple: same database, separate tables. Medium: separate databases with async replication. Complex: multiple specialized read models with event sourcing.
CQRS pairs well with event sourcing. The write model appends events. Read models subscribe to events and build projections. Events are the synchronization mechanism.
Traditional applications use a single model for both reads and writes. This forces compromises that hurt both operations. Write optimization (normalization) hurts read performance. Read optimization (denormalization) complicates writes.
| Aspect | Advantage | Disadvantage |
|---|---|---|