Dans cet article
Suivre un client au-delà de la requête HTTP
Imaginons deux organisations utilisant un produit de réservation partagé. Chacune peut posséder une réservation numéro 42. Un cache utilisant uniquement ce numéro peut transmettre les données de l’une à l’autre, même si les requêtes SQL sont correctes. Le même risque existe dans les fichiers, index de recherche, exports et notifications asynchrones.
Déduisez l’identité du client de l’appartenance authentifiée et vérifiez côté serveur l’organisation sélectionnée. Transmettez ce contexte aux tâches asynchrones : un worker n’hérite pas de la session du navigateur. Adaptez les identifiants et clés de cache. Lorsqu’un administrateur change d’organisation, montrez-le dans l’interface et vérifiez son appartenance. Un identifiant envoyé par le navigateur est une demande à contrôler, pas une autorisation.
L’identité du client accompagne la requête
L’isolation doit tenir sur tout le parcours, y compris les traitements différés.
Identité
Authentifier l’appelant et identifier son organisation.
Autorisation
Contrôler l’opération et l’enregistrement visé.
Frontière de données
Appliquer systématiquement le modèle d’isolation retenu.
Traitement différé
Conserver le même contexte dans traitements, exports et journaux.
Traiter la tenancy comme un invariant système
Un tenant n’est pas seulement une clé étrangère. Il définit qui peut agir, quelle configuration s’applique, comment les données sont isolées, comment l’usage est mesuré et ce qui se passe lors d’une suspension, d’un export ou d’une suppression.
Choisissez un contexte tenant canonique lors de l’authentification et transmettez-le aux commandes, requêtes, jobs, caches, fichiers et à la télémétrie. Un contexte absent doit échouer de manière fermée, sans revenir à un tenant par défaut.
Choisir l’isolation selon les conséquences et l’exploitation
Des tables partagées sont efficaces à exploiter mais exigent isolation de lignes et tests partout. Des schémas ou bases séparés augmentent l’isolation et la complexité des migrations. Le choix dépend de la sensibilité, du risque noisy neighbour, de la granularité de restauration et de la capacité d’exploitation.
Documentez où résident configuration, secrets et clés de chiffrement. Un modèle mixte peut isoler seulement certains tenants réglementés ou volumineux, mais il exige un contrat de routage unique et un lifecycle cohérent.
Concevoir lifecycle et reprise avant la facturation
Provisioning, invitations, changements de rôles, transitions de plan, limites, suspension et suppression doivent être des workflows idempotents. L’état de facturation ne doit pas devenir silencieusement l’état d’autorisation sans politique documentée de grâce et de reprise.
Observez usage et erreurs par tenant sans exposer de données personnelles. Répétez export et restauration pour un tenant et testez qu’une migration échouée ne laisse pas une partie du parc sur des schémas incompatibles.
Choisir l’isolation à partir d’un scénario de reprise
Des tables partagées peuvent simplifier l’exploitation ; des schémas ou bases séparés facilitent certains travaux d’isolation et de restauration, au prix de davantage de migrations, connexions et supervision. Aucune topologie ne remplace l’autorisation applicative. Comparez les conséquences d’un export, d’une restauration individuelle ou d’une conservation particulière pour un seul client.
La sécurité par ligne de PostgreSQL peut limiter les lignes accessibles à un rôle, mais propriétaires et rôles privilégiés disposent de mécanismes de contournement importants. Testez avec le vrai rôle d’exécution, pas seulement un compte administrateur. Si le pool de connexions transporte le contexte, vérifiez sa remise à zéro entre requêtes. La politique de base doit renforcer la frontière applicative, avec des essais explicites de lecture et d’écriture entre clients.
L’isolation est aussi un choix d’exploitation
Compromis qualitatifs à tester sur votre charge. Toutes les options exigent une autorisation.
Faites défiler horizontalement pour lire le tableau →
| Topologie | Avantage opérationnel | Travail à prévoir |
|---|---|---|
| Tables partagées | Moins de bases à exploiter | Requêtes et caches cloisonnés, stratégie de restauration |
| Schéma par client | Séparation logique des structures | Coordination des migrations et contexte de connexion |
| Base par client | Frontières distinctes de sauvegarde et ressources | Migrations, accès et supervision de chaque base |
Éprouver tout le cycle de vie d’un client
La création doit pouvoir reprendre après interruption : organisation, premier administrateur et configuration ne doivent pas laisser un compte invisible à moitié créé. La suspension doit arrêter les actions prévues sans détruire les informations nécessaires au support. La suppression doit couvrir index, exports, fichiers et sauvegardes, pas seulement les lignes de la base principale.
Testez aussi les effets d’un client très consommateur. Son import volumineux ne doit pas épuiser tous les workers ni bloquer les petites demandes interactives. Suivez si possible ancienneté des files et ressources par client, puis choisissez répartition ou quotas selon le produit. L’architecture doit expliquer confidentialité et qualité de service pour chaque organisation, y compris pendant les incidents.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Chaque tenant doit-il avoir sa propre base ?+
Non. Utilisez des bases séparées lorsque isolation, charge, exigences contractuelles ou restauration justifient le travail supplémentaire de routage et d’exploitation.