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.
Full FlowZap Code
UI { # Task-Based UI
n1: circle label:"User Intent"
n2: rectangle label:"Render Task Form"
n3: rectangle label:"Capture User Intent as Command"
n4: rectangle label:"Submit Command"
n5: rectangle label:"Show Optimistic Update"
n6: circle label:"UI Updated"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="PlaceOrder"]
n3.handle(right) -> n4.handle(left) [label="Command DTO"]
n4.handle(bottom) -> CommandAPI.n7.handle(top) [label="POST /commands"]
n4.handle(right) -> n5.handle(left) [label="Optimistic"]
n5.handle(right) -> n6.handle(left)
}
CommandAPI { # Command API
n7: rectangle label:"Deserialize Command"
n8: rectangle label:"Authorize User"
n9: diamond label:"Idempotency Check"
n10: rectangle label:"Dispatch to Handler"
n11: rectangle label:"Return 202 Accepted"
n12: rectangle label:"Return 409 Duplicate"
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left) [label="New"]
n9.handle(bottom) -> n12.handle(top) [label="Duplicate"]
n10.handle(right) -> n11.handle(left) [label="Queued"]
n11.handle(top) -> UI.n5.handle(bottom) [label="202"]
n10.handle(bottom) -> Domain.n13.handle(top) [label="Process"]
}
Domain { # Domain Model
n13: rectangle label:"Load Aggregate"
n14: rectangle label:"Execute Business Logic"
n15: rectangle label:"Persist State Change"
n16: rectangle label:"Emit Events"
n13.handle(right) -> n14.handle(left) [label="Current State"]
n14.handle(right) -> n15.handle(left) [label="New State"]
n15.handle(right) -> n16.handle(left) [label="Committed"]
n16.handle(bottom) -> QuerySync.n17.handle(top) [label="Async"]
}
QuerySync { # Query Synchronization
n17: rectangle label:"Update Read Model"
n18: rectangle label:"Push via WebSocket"
n19: rectangle label:"Invalidate Cache"
n17.handle(right) -> n18.handle(left) [label="Real-Time"]
n18.handle(top) -> UI.n6.handle(bottom) [label="Confirmed Update"]
n17.handle(right) -> n19.handle(left)
}
Why This Workflow?
Traditional CRUD forms map poorly to complex business operations—a "Place Order" action involves validation, payment, inventory, and shipping, not a simple database row update. Task-based UIs capture user intent as explicit commands, enabling optimistic updates, async processing, and real-time confirmation via WebSocket.
How It Works
- Step 1: The UI renders a task form that captures user intent (e.g., "Place Order" not "Update Row").
- Step 2: User intent is serialized as a command DTO and submitted to the Command API.
- Step 3: The UI immediately shows an optimistic update while the command processes asynchronously.
- Step 4: The Command API checks idempotency, authorizes the user, and dispatches to the domain.
- Step 5: After processing, the read model is updated and a WebSocket push confirms the real state.
- Step 6: Cache invalidation ensures subsequent reads reflect the latest state.
Alternatives
Traditional CRUD forms are simpler but cannot express complex business intent. Polling for updates adds latency. Server-Sent Events are simpler than WebSockets for one-way updates. This template shows the full task-based UI with optimistic updates.
Key Facts
| Template Name | CQRS Task-Based UI 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 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 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.