À retenir
- La plupart des produits B2B devraient démarrer avec une base partagée et une isolation au niveau des lignes.
- Déplacer certains locataires vers leur propre schéma ou base quand la conformité ou la taille l'exige.
- Imposer le contexte locataire dans la couche de données, pas seulement dans le code applicatif.
- Prévoir dès le départ les exports et sauvegardes par locataire.
La multi-location est l'une des décisions les plus coûteuses à défaire dans un produit SaaS. Une comparaison concrète des trois modèles courants et des signaux qui doivent guider le choix.
Les trois modèles courants
Les systèmes multi-locataires utilisent généralement l'un de trois modèles, qui arbitrent différemment entre isolation et charge d'exploitation.
- Base partagée, tables partagées : chaque ligne porte un identifiant de locataire. Le moins cher à exploiter, le plus simple à déployer, l'isolation la plus faible par défaut.
- Base partagée, schéma par locataire : les tables sont dupliquées par locataire dans une même base. Meilleure isolation, migrations plus complexes.
- Base par locataire : l'isolation la plus forte et la sauvegarde par locataire la plus simple, la charge d'exploitation la plus élevée.
Un choix par défaut raisonnable
Pour la plupart des jeunes produits B2B, des tables partagées avec un identifiant de locataire sur chaque ligne sont le bon point de départ. L'infrastructure reste simple, et les tâches transverses – facturation, analytique, support – restent faciles.
Le risque est une fuite de données due à un filtre oublié. Traitez-le dans la base, pas seulement dans le code : les politiques de sécurité au niveau des lignes de PostgreSQL, par exemple, peuvent imposer que chaque requête soit limitée au locataire courant – même si un développeur l'oublie.
Les signaux qui justifient plus d'isolation
Une isolation plus forte se justifie lorsque certaines conditions apparaissent. Elle doit rarement s'appliquer à tous les locataires.
- Un grand client exige contractuellement un stockage dédié.
- La réglementation impose de conserver les données dans une région précise.
- Le volume de données d'un locataire dégrade les performances des autres.
- Les clients ont besoin de sauvegardes et restaurations indépendantes.
Prévoir un modèle hybride
La conception la plus pragmatique à long terme prend en charge plusieurs modèles : la plupart des locataires partagent l'infrastructure, quelques grands locataires ou locataires réglementés ont leur propre base. Ce n'est possible que si la résolution du locataire se fait à un seul endroit – en général une couche de routage qui associe chaque requête à la bonne connexion.
Construisez cette couche de routage tôt, même si au début elle renvoie toujours la même base. C'est peu coûteux maintenant et très utile plus tard.
Les détails d'exploitation qui comptent
La multi-location ne concerne pas que le schéma. La limitation de débit, les tâches en arrière-plan, les chemins de stockage des fichiers, les caches et les journaux ont tous besoin du contexte locataire. De même que les fonctions visibles par les clients comme l'export des données et la suppression de compte, que les grands comptes demanderont lors de l'achat.
Cet article vous a plu ? Recevez le prochain par e-mail.