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.
Full FlowZap Code
WriteModel { # Write Model
n1: circle label:"Incoming Command"
n2: rectangle label:"Command Handler"
n3: rectangle label:"Validate Against Aggregate"
n4: rectangle label:"Persist to Write Store"
n5: rectangle label:"Emit Domain Event"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Normalized"]
n4.handle(right) -> n5.handle(left) [label="After Commit"]
n5.handle(bottom) -> EventBus.n6.handle(top) [label="Publish"]
}
EventBus { # Event Bus
n6: rectangle label:"Route Event"
n7: rectangle label:"Guarantee Ordering"
n8: rectangle label:"Deliver to Projectors"
n6.handle(right) -> n7.handle(left) [label="Partition Key"]
n7.handle(right) -> n8.handle(left)
n8.handle(bottom) -> Projectors.n9.handle(top) [label="Fan-Out"]
}
Projectors { # View Projectors
n9: rectangle label:"Order Summary Projector"
n10: rectangle label:"Customer Dashboard Projector"
n11: rectangle label:"Analytics Projector"
n12: rectangle label:"Search Index Projector"
n9.handle(bottom) -> Views.n13.handle(top) [label="Build View"]
n10.handle(bottom) -> Views.n14.handle(top) [label="Build View"]
n11.handle(bottom) -> Views.n15.handle(top) [label="Build View"]
n12.handle(bottom) -> Views.n16.handle(top) [label="Build View"]
}
Views { # Materialized Views
n13: rectangle label:"Order Summary Table"
n14: rectangle label:"Customer Dashboard Cache"
n15: rectangle label:"Analytics Cube"
n16: rectangle label:"Elasticsearch Index"
n17: rectangle label:"Query API"
n18: circle label:"Fast Read Response"
n13.handle(right) -> n17.handle(left)
n14.handle(right) -> n17.handle(left)
n15.handle(right) -> n17.handle(left)
n16.handle(right) -> n17.handle(left)
n17.handle(right) -> n18.handle(left) [label="Sub-ms Latency"]
}
Why This Workflow?
Different consumers need different views of the same data: dashboards need aggregations, search needs full-text indexes, and APIs need denormalized joins. Materialized views built from a single event stream allow each consumer to have a purpose-built read model without complex cross-service queries.
How It Works
- Step 1: The write model persists changes and emits domain events to the event bus.
- Step 2: The event bus guarantees ordered delivery to all registered projectors.
- Step 3: Each projector builds a specific materialized view: order summaries, dashboards, analytics cubes, or search indexes.
- Step 4: Views are stored in technology-appropriate stores (Redis, Elasticsearch, OLAP cubes).
- Step 5: The query API routes requests to the appropriate materialized view.
- Step 6: Views can be rebuilt from scratch by replaying the event stream.
Alternatives
Database views and materialized views work for single-database scenarios. GraphQL federation can compose data without materialized views. This template shows how to build multiple optimized read models from a single event stream.
Key Facts
| Template Name | CQRS Materialized View 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 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.
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.
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.