Alegerea unei arhitecturi multi-tenancy este una dintre cele mai importante decizii în proiectarea platformelor SaaS. Afectează structura costurilor, izolarea datelor, caracteristicile de performanță și complexitatea operațională pe toată durata de viață a produsului. Cele trei tipare dominante sunt baza de date partajată cu discriminare prin ID de tenant, schemă per tenant în cadrul unui server de baze de date partajat și bază de date complet izolată per tenant. Fiecare tipar ocupă un punct diferit pe spectrul dintre eficiența operațională și izolarea tenantului. Am construit platforme SaaS de producție folosind toate cele trei și putem oferi îndrumări concrete pentru potrivirea tiparului cu contextul de business.
Tiparul bazei de date partajate stochează toate datele tenantului în tabele comune, distinse printr-o coloană de ID tenant. Aceasta este abordarea cea mai eficientă din punct de vedere al costurilor deoarece infrastructura scalează cu volumul total de date, nu cu numărul de tenanți. Adăugarea unui nou tenant este instantanee și nu necesită provizionare. Cu toate acestea, acest tipar necesită disciplină riguroasă în proiectarea interogărilor: fiecare interogare trebuie să includă filtrul de ID tenant, iar un filtru omis înseamnă o scurgere catastrofală de date. Atenuăm acest risc cu politici de securitate la nivel de rând la nivelul bazei de date și middleware obligatoriu de context tenant care injectează filtrul automat. Izolarea performanței este cealaltă provocare, deoarece un singur tenant care rulează interogări grele poate impacta pe toți ceilalți fără o guvernanță atentă a resurselor.
Schema per tenant oferă o izolare logică mai puternică în timp ce partajează serverul de baze de date subiacent. Fiecare tenant primește propria schemă cu structuri de tabele identice, iar aplicația comută schemele în funcție de contextul tenantului autentificat. Acest tipar simplifică conversațiile despre conformitate deoarece poți demonstra limite clare ale datelor, iar migrările specifice schemei per tenant devin posibile pentru personalizarea enterprise. Costul operațional crește liniar cu numărul de tenanți, deoarece fiecare schemă necesită gestionare independentă a migrărilor. Am constatat că acest tipar funcționează bine pentru produsele SaaS B2B cu zeci până la sute de tenanți unde cerințele de izolare a datelor sunt moderate și se așteaptă o oarecare personalizare per tenant.
Baza de date per tenant oferă cele mai puternice garanții de izolare. Fiecare tenant are o instanță de bază de date complet independentă, potențial pe hardware dedicat. Acest tipar este necesar când tenanții au cerințe reglementare pentru rezidența datelor, când izolarea performanței trebuie să fie absolută sau când tenanții au nevoie de posibilitatea de a-și aduce propriile chei de criptare. Compromisul este o suprasarcină operațională semnificativă: provizionarea, monitorizarea, backup-ul și migrarea trebuie automatizate pentru fiecare instanță de tenant. Costul scalează direct cu numărul de tenanți indiferent de utilizare. Recomandăm acest tipar pentru produsele SaaS de clasă enterprise cu mai puțin de o sută de tenanți de mare valoare unde cerințele de izolare justifică investiția în infrastructură.