Multi-tenancy is de bouwsteen van vrijwel elk SaaS-product. De term klinkt abstract, maar de vraag is concreet: hoe bedien je honderden klanten op dezelfde infrastructuur zonder dat hun data door elkaar loopt en zonder dat de acties van klant A invloed hebben op de ervaring van klant B?
Dit artikel gaat over de architectuurkeuzes die daarvoor nodig zijn, de beveiligingsrisico's die je moet kennen en hoe je dit schaalbaar organiseert in een Nederlandse hostingomgeving.
Wat multi-tenancy betekent in de praktijk
Bij multi-tenancy delen meerdere klanten (tenants) dezelfde applicatie-instantie en infrastructuur. Ze zien alleen hun eigen data, maar de code die die data verwerkt is identiek. Dit is fundamenteel anders dan dedicated omgevingen, waarbij elke klant een eigen server of VM heeft.
De voordelen zijn aanzienlijk. Je beheert één codebase, rolt updates uit naar alle klanten tegelijk en deelt infrastructuurkosten. Een applicatie met duizend tenants op gedeelde infra kost een fractie van wat duizend losse VMs zouden kosten.
De uitdagingen zitten in drie gebieden: data-isolatie, resource-isolatie en tenant-specifieke configuratie.
Data-isolatie: drie modellen
Hoe je data opslaat bepaalt je isolatieprofiel. Er zijn drie gangbare modellen, elk met eigen afwegingen:
Shared database, shared schema: alle tenants in dezelfde tabellen, gescheiden door een tenant_id kolom. Maximale efficiëntie, laagste kosten per tenant. Row-Level Security (RLS) in PostgreSQL is hiervoor de meest gebruikte techniek. Het risico: een bug in je RLS-definitie legt data van alle tenants bloot. Dit model vraagt om solide testcoverage op isolatielogica.
Shared database, separate schema: elke tenant krijgt een eigen schema binnen dezelfde database. Beter isoleerbaar, iets hogere overhead per tenant. Goed te combineren met database-level permissies. Praktisch maximaal haalbaar bij enkele honderden tenants op één databaseserver.
Separate database per tenant: maximale isolatie, eenvoudigste compliance-verhaal. Veel hogere kosten en beheeroverhoofd. Zinvol voor enterprise-klanten met eigen compliancevereisten, of als onderdeel van een tiered-prijsmodel waarbij dit als premium feature wordt aangeboden.
Multi-tenancy modellen vergeleken
| Model | Isolatie | Kosten/tenant | Beheer | Geschikt voor |
|---|---|---|---|---|
| Shared schema | Laag | Laagst | Eenvoudig | SMB, hoge schaal |
| Separate schema | Middel | Gemiddeld | Matig | Mid-market |
| Separate database | Hoog | Hoogst | Complex | Enterprise, regulering |
Resource-isolatie: noisy neighbour voorkomen
Data-isolatie is één ding. Resource-isolatie is een andere uitdaging. Als één tenant een zware query draait, mag dat geen impact hebben op de responstijden van andere tenants. Dit heet het noisy-neighbour-probleem en het komt in vrijwel elke gedeelde omgeving voor.
Oplossingen op infrastructuurniveau:
- Rate limiting op API-niveau: begrens het aantal requests per tenant per tijdseenheid. Standaard in API-gateways als Kong of Nginx.
- Database connection pooling: PgBouncer of vergelijkbaar voorkomt dat één tenant alle connecties opeist.
- Kubernetes resource quotas: bij containergebaseerde deployments kun je per namespace CPU en geheugen begrenzen.
- Queue-gebaseerde verwerking: zware taken (exports, rapporten) gaan via een wachtrij met separate workers, niet inline via de API.
Voor grotere tenants is het zinvol om dedicated resources aan te bieden als premium optie. Zo behoud je de efficiëntie van multi-tenancy voor kleinere klanten en kun je enterprise-deals sluiten met klanten die garanties nodig hebben.
Authenticatie en autorisatie
In een multi-tenant systeem moet elke API-call weten welke tenant hij bedient en of de gebruiker rechten heeft op de gevraagde resource. Dit vraagt om een goed doordacht IAM-model.
Gangbare aanpak: JWT-tokens met een tenant_id claim. Elke request bevat een token dat de tenant en de gebruikersrol identificeert. Je middleware valideert dit token en injecteert de tenant-context voordat de request de businesslogica bereikt.
Valkuil: autorisatielogica die verspreid is door de codebase in plaats van gecentraliseerd. Dat leidt vroeg of laat tot een lek. Gebruik een centrale autorisatielaag (Policy-Based Access Control of Attribute-Based Access Control) die consistent gehandhaafd wordt.
Schaalstrategie per groeimoment
Een multi-tenant architectuur schaal je anders dan een single-tenant applicatie. De meeste groeipijnen ontstaan niet bij meer tenants, maar bij een kleine groep tenants die disproportioneel veel resources gebruiken.
Monitoring per tenant is daarvoor onmisbaar. Je wil weten welke tenants het meeste database-verkeer genereren, de langste queries hebben en de meeste API-calls doen. Zonder die inzichten reageer je blind op capaciteitsproblemen.
Wanneer welke schaalstap?
Beveiliging: wat mis kan gaan
De grootste beveiligingsrisico's in multi-tenant applicaties zijn niet spectaculair. Ze zijn het gevolg van kleine fouten in alledaagse code:
- Een query die vergeet te filteren op tenant_id
- Een API endpoint dat objecten ophaalt op basis van een ID zonder eigenaarcontrole (Insecure Direct Object Reference)
- Gedeelde caches waarbij de cache-key niet tenant-specifiek is
- Log-bestanden die tenant-data van meerdere klanten door elkaar mengen
Penetratietests voor multi-tenant applicaties testen specifiek op cross-tenant data leakage. Plan dit in voordat je gevoelige klantdata verwerkt, niet erna.
Hosting in Nederland: wat het toevoegt
Multi-tenant architectuur in combinatie met hosting buiten de EU brengt AVG-risico's. Je verwerkt data van meerdere klanten die elk hun eigen klanten hebben. Die gelaagdheid maakt datasoevereiniteit complex. Hosting in een Nederlands datacenter met duidelijke verwerkersovereenkomsten maakt het complianceverhaal transparant en controleerbaar, voor jou en voor je klanten.
Op zoek naar schaalbare SaaS-hosting? Bekijk onze SaaS-oplossingen.