Architecture
A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical.
Full FlowZap Code
Client { # Client Application
n1: circle label:"User Action"
n2: diamond label:"Read or Write?"
n3: rectangle label:"Display Query Result"
n4: rectangle label:"Confirm Write Success"
n5: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> ReadPath.n10.handle(left) [label="Query"]
n2.handle(bottom) -> WritePath.n6.handle(top) [label="Command"]
n3.handle(right) -> n5.handle(left)
n4.handle(right) -> n5.handle(left)
}
WritePath { # Write Path (Command)
n6: rectangle label:"Command Validator"
n7: rectangle label:"Domain Aggregate"
n8: rectangle label:"Write Database (PostgreSQL)"
n9: rectangle label:"Publish Change Event"
n6.handle(right) -> n7.handle(left) [label="Validated"]
n7.handle(right) -> n8.handle(left) [label="Persist"]
n8.handle(right) -> n9.handle(left) [label="Committed"]
n9.handle(bottom) -> Sync.n14.handle(top) [label="DomainEvent"]
n8.handle(top) -> Client.n4.handle(bottom) [label="ACK"]
}
ReadPath { # Read Path (Query)
n10: rectangle label:"Query Router"
n11: rectangle label:"Read Database (Redis/Elastic)"
n12: rectangle label:"Transform to DTO"
n13: rectangle label:"Return Response"
n10.handle(right) -> n11.handle(left) [label="Optimized Query"]
n11.handle(right) -> n12.handle(left) [label="Denormalized"]
n12.handle(right) -> n13.handle(left)
n13.handle(top) -> Client.n3.handle(bottom) [label="JSON"]
}
Sync { # Synchronization Layer
n14: rectangle label:"Event Consumer"
n15: rectangle label:"Transform for Read Model"
n16: rectangle label:"Update Read Database"
n17: diamond label:"Lag Acceptable?"
n18: rectangle label:"Alert on Lag"
n14.handle(right) -> n15.handle(left) [label="Consume"]
n15.handle(right) -> n16.handle(left) [label="Upsert"]
n16.handle(right) -> n17.handle(left)
n17.handle(top) -> ReadPath.n11.handle(bottom) [label="Yes"]
n17.handle(bottom) -> n18.handle(top) [label="No"]
}
Why This Workflow?
Applications with 100:1 read-to-write ratios waste resources when the same database handles both workloads. CQRS read-write separation uses optimized stores for each path—a normalized relational database for writes and a denormalized cache or search index for reads—enabling each to scale independently.
How It Works
- Step 1: Write requests go through the command validator and domain aggregate.
- Step 2: Validated changes are persisted to PostgreSQL (write-optimized, normalized).
- Step 3: A change event is published to the synchronization layer.
- Step 4: The event consumer transforms data and updates the read database (Redis or Elasticsearch).
- Step 5: Read requests are served directly from the optimized read store with sub-millisecond latency.
- Step 6: Lag monitoring alerts if the read model falls too far behind the write model.
Alternatives
Read replicas provide simpler read scaling but limit query optimization. Materialized views in PostgreSQL work for moderate read loads. This template shows the full CQRS separation with independent read/write stores.
Key Facts
| Template Name | CQRS Read-Write Separation Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.
Architecture
A CQRS materialized view architecture diagram with multiple projectors building purpose-specific read models: order summaries, customer dashboards, analytics cubes, and search indexes, all fed from a single event stream. This template shows how to create multiple optimized query views from the same write events, each tailored to a specific use case with sub-millisecond read latency. Perfect for systems requiring diverse query patterns from a single data source.
Architecture
A CQRS task-based UI architecture diagram where the frontend captures user intent as explicit commands, submits them asynchronously with optimistic updates, and receives real-time confirmations via WebSocket when the read model is synchronized. This template models the modern UI pattern that replaces CRUD forms with intent-driven commands, enabling responsive user experiences with eventual consistency. Recommended for teams building reactive frontends on CQRS backends.
Architecture
A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.