Outbox 模式可靠消息架构

Architecture

事务性 Outbox 架构图，领域写入和事件发布在同一数据库事务中完成，中继进程轮询 outbox 表并将事件发布到消息代理以保证交付。该模板解决了更新数据库和发布事件不是原子操作的双写问题，确保无需分布式事务即可实现精确一次事件交付。对于需要可靠消息发布的事件驱动架构至关重要。

下载 .fz 文件

完整 FlowZap 代码

Application { # Application Service
n1: circle label:"Business Operation"
n2: rectangle label:"Begin Transaction"
n3: rectangle label:"Update Domain Table"
n4: rectangle label:"Insert into Outbox Table"
n5: rectangle label:"Commit Transaction"
n6: circle label:"Return Success"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Atomic"]
n3.handle(right) -> n4.handle(left) [label="Same TX"]
n4.handle(right) -> n5.handle(left) [label="Commit"]
n5.handle(right) -> n6.handle(left)
n4.handle(bottom) -> Database.n7.handle(top) [label="Write"]
}
Database { # Database
n7: rectangle label:"Domain Table (Orders)"
n8: rectangle label:"Outbox Table (Events)"
n9: rectangle label:"Outbox Row: Pending"
n7.handle(right) -> n8.handle(left) [label="Same Database"]
n8.handle(right) -> n9.handle(left) [label="Status: PENDING"]
n9.handle(bottom) -> Relay.n10.handle(top) [label="Poll"]
}
Relay { # Outbox Relay (Debezium/Poller)
n10: rectangle label:"Poll Outbox Table"
n11: rectangle label:"Read Pending Events"
n12: rectangle label:"Publish to Message Broker"
n13: diamond label:"Published Successfully?"
n14: rectangle label:"Mark as Processed"
n15: rectangle label:"Retry with Backoff"
n10.handle(right) -> n11.handle(left) [label="SELECT WHERE status=PENDING"]
n11.handle(right) -> n12.handle(left) [label="Serialize"]
n12.handle(right) -> n13.handle(left)
n13.handle(right) -> n14.handle(left) [label="Yes"]
n13.handle(bottom) -> n15.handle(top) [label="No"]
n14.handle(top) -> Database.n9.handle(bottom) [label="UPDATE status=DONE"]
n15.handle(top) -> n12.handle(bottom) [label="Retry"]
}
Consumers { # Downstream Consumers
n16: rectangle label:"Notification Service"
n17: rectangle label:"Analytics Service"
n18: rectangle label:"Search Index Service"
n12.handle(bottom) -> Consumers.n16.handle(top) [label="OrderCreated"]
n12.handle(bottom) -> Consumers.n17.handle(top) [label="OrderCreated"]
n12.handle(bottom) -> Consumers.n18.handle(top) [label="OrderCreated"]
}

为什么需要这个工作流？

Publishing an event to a message broker after updating a database is a dual-write problem—if the broker publish fails after the database commit, the event is lost. The outbox pattern solves this by writing both the domain change and the event to the same database transaction, then reliably relaying events to the broker.

工作原理

Step 1: The application begins a database transaction.
Step 2: The domain table is updated with the business data change.
Step 3: An event record is inserted into the outbox table within the same transaction.
Step 4: The transaction commits atomically, guaranteeing both writes succeed or fail together.
Step 5: A relay process (Debezium CDC or polling) reads pending outbox events.
Step 6: Events are published to the message broker and marked as processed in the outbox table.

替代方案

Application-level event publishing risks data inconsistency on partial failures. CDC without an outbox table captures all changes, not just domain events. This template shows the transactional outbox pattern for guaranteed event delivery.

Key Facts

Template Name	Outbox 模式可靠消息架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)