Architecture
A multi-tenant SaaS architecture diagram with tenant identification, tier-based routing (shared vs dedicated pools), row-level security, per-tenant encryption keys, and isolated backup strategies for standard and enterprise isolation models. This template models the architecture decisions for building SaaS platforms that serve multiple customers from shared infrastructure while maintaining strict data isolation. Critical for SaaS architects balancing cost efficiency with enterprise security requirements.
Tenant { # Tenant Request
n1: circle label:"Tenant API Call"
n2: rectangle label:"Tenant Identification"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left) [label="X-Tenant-ID"]
n2.handle(bottom) -> Routing.n5.handle(top) [label="Resolve Tenant"]
n3.handle(right) -> n4.handle(left)
}
Routing { # Tenant Routing Layer
n5: rectangle label:"Tenant Config Lookup"
n6: diamond label:"Isolation Model?"
n7: rectangle label:"Route to Shared Pool"
n8: rectangle label:"Route to Dedicated Pool"
n9: rectangle label:"Apply Tenant Rate Limits"
n5.handle(right) -> n6.handle(left) [label="Tier"]
n6.handle(right) -> n7.handle(left) [label="Standard Tier"]
n6.handle(bottom) -> n8.handle(top) [label="Enterprise Tier"]
n7.handle(right) -> n9.handle(left)
n8.handle(right) -> n9.handle(left)
n9.handle(bottom) -> Application.n10.handle(top) [label="Tenant Context"]
}
Application { # Application Layer
n10: rectangle label:"Inject Tenant Context"
n11: rectangle label:"Execute Business Logic"
n12: rectangle label:"Apply Row-Level Security"
n13: rectangle label:"Return Tenant-Scoped Data"
n10.handle(right) -> n11.handle(left) [label="Middleware"]
n11.handle(right) -> n12.handle(left) [label="Query"]
n12.handle(right) -> n13.handle(left) [label="Filtered"]
n13.handle(top) -> Tenant.n3.handle(bottom) [label="Response"]
n12.handle(bottom) -> DataLayer.n14.handle(top) [label="Tenant Filter"]
}
DataLayer { # Data Isolation
n14: rectangle label:"Shared Database (Schema per Tenant)"
n15: rectangle label:"Dedicated Database (Enterprise)"
n16: rectangle label:"Tenant Encryption Keys"
n17: rectangle label:"Backup per Tenant"
n14.handle(right) -> n16.handle(left) [label="Encrypt at Rest"]
n15.handle(right) -> n16.handle(left) [label="Dedicated Key"]
n16.handle(right) -> n17.handle(left) [label="Isolated Backup"]
}
SaaS platforms must serve multiple customers from shared infrastructure while maintaining strict data isolation, security, and performance guarantees. The multi-tenant architecture balances cost efficiency (shared resources) with enterprise requirements (dedicated isolation) through tier-based routing and row-level security.
Single-tenant deployments are simpler but expensive to operate at scale. Shared-everything models are cheapest but risk data leakage. This template shows the hybrid approach with tier-based isolation levels.
| Template Name | Multi-Tenant SaaS 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 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.
Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.