Architecture
Diagramme d'architecture SaaS multi-tenant avec identification du tenant, routage basé sur le niveau (pools partagés vs dédiés), sécurité au niveau des lignes, clés de chiffrement par tenant et stratégies de sauvegarde isolées pour les modèles d'isolation standard et entreprise. Ce modèle représente les décisions architecturales pour construire des plateformes SaaS servant plusieurs clients depuis une infrastructure partagée tout en maintenant une isolation stricte des données. Critique pour les architectes SaaS équilibrant l'efficacité des coûts avec les exigences de sécurité entreprise.
Code FlowZap complet
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"]
}
Pourquoi ce workflow ?
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.
Comment ça fonctionne
- Step 1: Each request includes a tenant identifier (header or subdomain).
- Step 2: The routing layer looks up tenant configuration and determines the isolation model.
- Step 3: Standard tier tenants share database schemas with row-level security filtering.
- Step 4: Enterprise tier tenants get dedicated database instances and connection pools.
- Step 5: Per-tenant rate limits prevent any single tenant from monopolizing shared resources.
- Step 6: Per-tenant encryption keys and isolated backups ensure data sovereignty compliance.
Alternatives
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.
Key Facts
| Template Name | Architecture SaaS multi-tenant |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.