Architecture
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
OrderService { # Order Service
n1: circle label:"New Order Received"
n2: rectangle label:"Validate Order"
n3: rectangle label:"Emit OrderCreated Event"
n4: rectangle label:"Listen for PaymentConfirmed"
n5: rectangle label:"Update Order Status"
n6: circle label:"Order Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(bottom) -> EventBus.n7.handle(top) [label="Publish"]
n4.handle(right) -> n5.handle(left) [label="Confirmed"]
n5.handle(right) -> n6.handle(left)
}
EventBus { # Event Bus
n7: rectangle label:"OrderCreated Topic"
n8: rectangle label:"PaymentConfirmed Topic"
n9: rectangle label:"InventoryReserved Topic"
n10: rectangle label:"ShipmentScheduled Topic"
n7.handle(bottom) -> PaymentService.n11.handle(top) [label="Subscribe"]
n8.handle(top) -> OrderService.n4.handle(bottom) [label="Notify"]
n8.handle(bottom) -> InventoryService.n14.handle(top) [label="Subscribe"]
n9.handle(bottom) -> ShippingService.n17.handle(top) [label="Subscribe"]
}
PaymentService { # Payment Service
n11: rectangle label:"Receive OrderCreated"
n12: rectangle label:"Process Payment"
n13: rectangle label:"Emit PaymentConfirmed"
n11.handle(right) -> n12.handle(left) [label="Charge"]
n12.handle(right) -> n13.handle(left) [label="Success"]
n13.handle(top) -> EventBus.n8.handle(bottom) [label="Publish"]
}
InventoryService { # Inventory Service
n14: rectangle label:"Receive PaymentConfirmed"
n15: rectangle label:"Reserve Stock"
n16: rectangle label:"Emit InventoryReserved"
n14.handle(right) -> n15.handle(left) [label="Allocate"]
n15.handle(right) -> n16.handle(left) [label="Reserved"]
n16.handle(top) -> EventBus.n9.handle(bottom) [label="Publish"]
}
ShippingService { # Shipping Service
n17: rectangle label:"Receive InventoryReserved"
n18: rectangle label:"Schedule Shipment"
n19: rectangle label:"Emit ShipmentScheduled"
n17.handle(right) -> n18.handle(left) [label="Plan Route"]
n18.handle(right) -> n19.handle(left) [label="Scheduled"]
n19.handle(top) -> EventBus.n10.handle(bottom) [label="Publish"]
}
Centralized orchestrators become bottlenecks and single points of failure as the number of services grows. Event-driven choreography distributes coordination logic across services, where each service reacts autonomously to events—eliminating the need for a central coordinator and enabling truly independent service deployment.
Orchestration-based sagas provide better visibility but create a central coordinator dependency. Choreography is harder to debug but more resilient. This template helps teams understand the event flow in a choreographed system.
| Template Name | Event-Driven Choreography Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
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 saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.
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 Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.
Architecture
An event-driven publish-subscribe architecture diagram with Kafka or RabbitMQ message broker, event serialization, topic partitioning, fan-out delivery to multiple consumers, and dead letter queue error handling. This template models the foundational async messaging pattern where producers and consumers are fully decoupled through a message broker. Essential for architects building loosely coupled, scalable event-driven systems.
Architecture
A domain events architecture diagram showing how aggregate roots raise domain events that are dispatched both in-process to local handlers and cross-boundary to integration event consumers in other bounded contexts. This template models the DDD event pattern where domain logic triggers side effects through a clean event dispatcher, maintaining separation between domain and infrastructure concerns. Key for teams implementing Domain-Driven Design with event-based integration.