Architecture
A transactional outbox architecture diagram where domain writes and event publishing happen in the same database transaction, with a relay process polling the outbox table and publishing events to a message broker with guaranteed delivery. This template solves the dual-write problem where updating a database and publishing an event are not atomic, ensuring exactly-once event delivery without distributed transactions. Critical for event-driven architectures requiring reliable message publishing.
Full FlowZap Code
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"]
}
Why This Workflow?
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.
How It Works
- 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.
Alternatives
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 Pattern for Reliable Messaging Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A Change Data Capture architecture diagram using Debezium to tail database transaction logs and publish change events to Kafka, feeding downstream consumers that update search indexes, invalidate caches, load data warehouses, and write audit logs. This template shows how CDC eliminates dual-write problems by capturing changes at the database level without modifying application code. Critical for data synchronization across heterogeneous systems.
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.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.