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.
Producer { # Event Producer
n1: circle label:"Business Action"
n2: rectangle label:"Create Domain Event"
n3: rectangle label:"Serialize Event"
n4: rectangle label:"Publish to Topic"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="OrderCreated"]
n3.handle(right) -> n4.handle(left) [label="Avro/JSON"]
n4.handle(bottom) -> Broker.n5.handle(top) [label="Produce"]
}
Broker { # Message Broker (Kafka/RabbitMQ)
n5: rectangle label:"Receive Event"
n6: rectangle label:"Partition by Key"
n7: rectangle label:"Persist to Log"
n8: rectangle label:"Fan-Out to Subscribers"
n9: rectangle label:"Dead Letter Queue"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Append"]
n7.handle(right) -> n8.handle(left) [label="Notify"]
n8.handle(bottom) -> Consumers.n10.handle(top) [label="Deliver"]
n9.handle(bottom) -> Consumers.n17.handle(top) [label="Failed Events"]
}
Consumers { # Event Consumers
n10: rectangle label:"Inventory Consumer"
n11: rectangle label:"Update Stock Level"
n12: rectangle label:"Notification Consumer"
n13: rectangle label:"Send Order Email"
n14: rectangle label:"Analytics Consumer"
n15: rectangle label:"Update Dashboard"
n16: diamond label:"Processing OK?"
n17: rectangle label:"Retry Handler"
n10.handle(right) -> n16.handle(left)
n16.handle(right) -> n11.handle(left) [label="Yes"]
n16.handle(bottom) -> n17.handle(top) [label="No"]
n17.handle(top) -> Broker.n9.handle(bottom) [label="DLQ"]
n12.handle(right) -> n13.handle(left) [label="Email"]
n14.handle(right) -> n15.handle(left) [label="Aggregate"]
}
Synchronous request-response communication between microservices creates tight coupling, cascading failures, and latency chains. The publish-subscribe pattern decouples producers from consumers through a message broker, enabling independent scaling, temporal decoupling, and resilient event processing with built-in retry mechanisms.
Synchronous HTTP calls are simpler but create coupling. Point-to-point queues limit fan-out. Managed services like AWS SNS/SQS or Google Pub/Sub reduce operational overhead. This template visualizes the complete pub/sub lifecycle including error handling.
| Template Name | Event-Driven Publish-Subscribe 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
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.
Architecture
A real-time event streaming pipeline architecture diagram with IoT sensors, application logs, and clickstream data flowing through Kafka into Apache Flink for window aggregation, anomaly detection, and multi-sink output to data lakes and dashboards. This template visualizes end-to-end stream processing from ingestion through transformation to storage and alerting. Essential for data engineers building real-time analytics and monitoring platforms.
Architecture
A dead letter queue architecture diagram with retry policies, exponential backoff, max retry thresholds, DLQ routing for failed messages, operations alerting, and manual reprocessing workflows. This template models the critical error handling pattern for asynchronous messaging systems, ensuring no message is silently lost when processing fails. Essential for building reliable event-driven systems with proper failure recovery mechanisms.
Architecture
An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures.
Architecture
An event-driven notification hub architecture diagram with multi-source event ingestion, template-based message rendering, user preference routing across email (SendGrid/SES), push (FCM), SMS (Twilio), and Slack channels, with delivery tracking and retry mechanisms. This template models a centralized notification system that decouples business services from delivery infrastructure, supporting multi-channel communication with user-controlled preferences. Ideal for platform teams building scalable notification infrastructure.