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.
Sources { # Data Sources
n1: rectangle label:"IoT Sensor Stream"
n2: rectangle label:"Application Logs"
n3: rectangle label:"User Clickstream"
n4: rectangle label:"Transaction Events"
n1.handle(bottom) -> Ingestion.n5.handle(top) [label="MQTT"]
n2.handle(bottom) -> Ingestion.n5.handle(top) [label="Fluentd"]
n3.handle(bottom) -> Ingestion.n6.handle(top) [label="Kafka Connect"]
n4.handle(bottom) -> Ingestion.n6.handle(top) [label="CDC"]
}
Ingestion { # Stream Ingestion (Kafka)
n5: rectangle label:"Kafka Topic: Raw Events"
n6: rectangle label:"Kafka Topic: Enriched Events"
n7: rectangle label:"Schema Registry Validate"
n8: rectangle label:"Partition by Key"
n5.handle(right) -> n7.handle(left) [label="Validate"]
n7.handle(right) -> n8.handle(left) [label="Schema OK"]
n8.handle(bottom) -> Processing.n9.handle(top) [label="Partitioned"]
n6.handle(bottom) -> Processing.n9.handle(top) [label="Stream"]
}
Processing { # Stream Processing (Flink/Spark)
n9: rectangle label:"Window Aggregation"
n10: rectangle label:"Filter and Transform"
n11: rectangle label:"Join Streams"
n12: diamond label:"Anomaly Detected?"
n13: rectangle label:"Emit Alert Event"
n14: rectangle label:"Write to Sink"
n9.handle(right) -> n10.handle(left) [label="5-min Window"]
n10.handle(right) -> n11.handle(left) [label="Cleaned"]
n11.handle(right) -> n12.handle(left) [label="Enriched"]
n12.handle(right) -> n14.handle(left) [label="Normal"]
n12.handle(bottom) -> n13.handle(top) [label="Anomaly"]
n13.handle(right) -> n14.handle(left) [label="Alert + Data"]
n14.handle(bottom) -> Sinks.n15.handle(top) [label="Output"]
}
Sinks { # Data Sinks
n15: rectangle label:"Data Lake (S3/HDFS)"
n16: rectangle label:"Real-Time Dashboard"
n17: rectangle label:"Alert Notification"
n18: rectangle label:"Search Index (Elasticsearch)"
n15.handle(right) -> n16.handle(left) [label="Batch Analytics"]
n17.handle(right) -> n18.handle(left)
}
Batch processing introduces hours of latency between data generation and insight. Real-time event streaming pipelines process data as it arrives, enabling immediate anomaly detection, live dashboards, and sub-second alerting—critical for IoT monitoring, fraud detection, and operational intelligence.
Batch ETL with Spark is simpler but adds hours of latency. Managed streaming services like AWS Kinesis or Google Dataflow reduce operational complexity. This template visualizes the end-to-end streaming pipeline architecture.
| Template Name | Event-Driven Streaming Pipeline 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 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 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 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.