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.
Gateway { # API Gateway
n1: circle label:"Client Request"
n2: rectangle label:"Route to Service"
n3: rectangle label:"Aggregate Responses"
n4: circle label:"Return to Client"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> UserService.n5.handle(top) [label="User Data"]
n2.handle(bottom) -> OrderService.n9.handle(top) [label="Order Data"]
n3.handle(right) -> n4.handle(left)
}
UserService { # User Service
n5: rectangle label:"Handle User Request"
n6: rectangle label:"Query User DB"
n7: rectangle label:"User PostgreSQL"
n8: rectangle label:"Return User Data"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="SELECT"]
n7.handle(right) -> n8.handle(left) [label="Result"]
n8.handle(top) -> Gateway.n3.handle(bottom) [label="User JSON"]
}
OrderService { # Order Service
n9: rectangle label:"Handle Order Request"
n10: rectangle label:"Query Order DB"
n11: rectangle label:"Order MongoDB"
n12: rectangle label:"Return Order Data"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left) [label="find()"]
n11.handle(right) -> n12.handle(left) [label="Documents"]
n12.handle(top) -> Gateway.n3.handle(bottom) [label="Order JSON"]
}
EventBus { # Event Bus (Kafka)
n13: rectangle label:"Publish Domain Event"
n14: rectangle label:"Event Topic"
n15: rectangle label:"Consume Event"
n16: rectangle label:"Sync Read Model"
n13.handle(right) -> n14.handle(left) [label="UserUpdated"]
n14.handle(right) -> n15.handle(left) [label="Subscribe"]
n15.handle(right) -> n16.handle(left)
n16.handle(top) -> OrderService.n11.handle(bottom) [label="Update Denormalized"]
n13.handle(top) -> UserService.n8.handle(bottom) [label="After Write"]
}
Sharing a single database across microservices creates tight coupling, schema change conflicts, and performance bottlenecks that defeat the purpose of microservices. The database-per-service pattern ensures each service owns its data, enabling independent deployment, technology-appropriate storage choices, and fault isolation.
Shared databases are simpler but create deployment coupling and single points of failure. Database-per-service with synchronous API calls creates latency chains. This template shows the event-driven approach that balances autonomy with data consistency.
| Template Name | Microservices Database-Per-Service Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
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
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 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
A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.
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.