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.
Full FlowZap Code
WriteAPI { # Write API (Command)
n1: circle label:"POST/PUT Request"
n2: rectangle label:"Command Handler"
n3: rectangle label:"Validate Business Rules"
n4: rectangle label:"Persist to Write DB"
n5: rectangle label:"Publish Domain Event"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Valid"]
n4.handle(right) -> n5.handle(left) [label="Committed"]
n5.handle(bottom) -> EventBus.n6.handle(top) [label="OrderPlaced"]
}
EventBus { # Event Bus (Kafka)
n6: rectangle label:"Receive Domain Event"
n7: rectangle label:"Route to Topic"
n8: rectangle label:"Guarantee Delivery"
n9: rectangle label:"Fan-Out to Consumers"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="At-Least-Once"]
n8.handle(right) -> n9.handle(left)
n9.handle(bottom) -> ReadSide.n10.handle(top) [label="Consume"]
n9.handle(bottom) -> Projector.n14.handle(top) [label="Consume"]
}
ReadSide { # Read API (Query)
n10: rectangle label:"Query Handler"
n11: rectangle label:"Read from Read DB"
n12: rectangle label:"Transform to DTO"
n13: circle label:"GET Response"
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Denormalized"]
n12.handle(right) -> n13.handle(left)
}
Projector { # Read Model Projector
n14: rectangle label:"Event Handler"
n15: rectangle label:"Update Read Model"
n16: rectangle label:"Rebuild Materialized View"
n17: diamond label:"Consistency Check"
n18: rectangle label:"Mark Projection Current"
n14.handle(right) -> n15.handle(left) [label="Transform"]
n15.handle(right) -> n16.handle(left) [label="Upsert"]
n16.handle(right) -> n17.handle(left)
n17.handle(right) -> n18.handle(left) [label="Consistent"]
n18.handle(top) -> ReadSide.n11.handle(bottom) [label="Updated"]
}
Why This Workflow?
Systems with high read-to-write ratios suffer when the same data model serves both commands and queries. CQRS with an event store separates the write path (optimized for consistency) from the read path (optimized for speed), allowing each to scale independently while domain events keep them synchronized.
How It Works
- Step 1: Write requests go through a command handler that validates business rules.
- Step 2: Valid commands are persisted to the write database and a domain event is published.
- Step 3: The event bus guarantees at-least-once delivery to all subscribed projectors.
- Step 4: Projectors transform domain events into denormalized read models optimized for specific queries.
- Step 5: The read API serves queries directly from the optimized read database.
- Step 6: Consistency checks monitor lag between write and read models.
Alternatives
A single database with read replicas is simpler but limits query optimization. GraphQL can reduce over-fetching without full CQRS. This template shows the complete CQRS+ES architecture for teams that need independent read/write scaling.
Key Facts
| Template Name | Event-Driven CQRS with Event Store Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
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.
patterns
CQRS (Command Query Responsibility Segregation) pattern with separate command and query paths, domain event publishing, read model synchronization, and DTO transformation.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.
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.
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.