CQRS 读写分离架构

Architecture

CQRS 读写分离架构图，展示专用的命令和查询路径，PostgreSQL 用于写入，Redis 或 Elasticsearch 用于优化读取，以及带有延迟监控的事件驱动同步层。该模板演示了 CQRS 的核心原则——分离读写模型以独立扩展和优化每条路径。适合读写比例不对称且查询性能至关重要的应用。

下载 .fz 文件

完整 FlowZap 代码

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"]
}

为什么需要这个工作流？

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.

工作原理

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.

替代方案

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 读写分离架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)