Multi-tenant SaaS-architectuur: isolatie en afwegingen

Vergelijk gedeelde en gescheiden resources voor data, taken en beheer. Maak tenantisolatie expliciet naast authenticatie.

Drie afzonderlijke tenantkamers verbonden met een gedeelde dienstenstructuur.

Multi-tenancy laat meerdere klantorganisaties één dienst gebruiken. De hoofdvraag is waar middelen gedeeld worden en hoe toegang en belasting begrensd blijven. Authenticatie vertelt wie belt, niet vanzelf welke tenantresources die persoon mag gebruiken. Behandel isolatie als eis voor elk pad, inclusief support en achtergrondverwerking.

Kies grenzen op basis van eisen

Model	Mogelijk voordeel	Beheervraag
Gedeelde tabellen met tenant-ID	Efficiëntie en gemeenschappelijke migraties	Hoe overal filtering afdwingen?
Gescheiden schema’s of databases	Duidelijker gegevensgrens	Hoe migraties en backups beheren?
Gescheiden deployments	Onafhankelijke capaciteit	Hoe de groeiende vloot onderhouden?

Modellen kunnen gecombineerd worden. Deel een controlplane en isoleer een bijzondere workload als dat nodig is. Leg reden en provisioningkeuze vast. Gescheiden databases garanderen geen isolatie wanneer credentials, supporttools of exports grenzen ongecontroleerd oversteken.

Geef vertrouwde context door

Bepaal lidmaatschap en rechten op de server. Een meegestuurde tenant-ID bewijst geen toegang. Neem context op in taken, cachesleutels, opslagpaden en auditlogs en controleer die bij resourcegebruik. Beoordeel beheeracties over tenants heen apart en beperk ze tot expliciete doelen.

Maak testaccounts in twee tenants met verschillende gegevens.
Controleer lezen, wijzigen, exports en bestanden per rol.
Test vertraagde taken en caches bij contextwissel.
Registreer actor, tenant en supportdoel.
Oefen herstel en verwijdering langs de gekozen grens.

Onderzoek ook belastingisolatie

Een zware import of rapportage kan anderen vertragen zonder data bloot te stellen. Gebruik waar nodig quota, planning of scheiding en meet representatieve belasting. Houd tenantinventaris en provisioning versieerbaar om verborgen uitzonderingen te voorkomen. Herzie keuzes wanneer klantvereisten of gebruik verandert.

Bewaar bewijs per pad en rol. Eén geslaagde test bewijst niet het hele systeem. Bekijk herstel: een gedeelde database terugzetten heeft andere gevolgen dan één tenant herstellen. Incidentbeheerders moeten die grens kennen. Dataprivacy en stabiele prestaties hangen samen, maar vereisen elk eigen verificatie.

Veelgestelde vragen

Is een tenant-ID in elke tabel genoeg?

Nee. Queries, taken, cache, bestanden en beheer moeten vertrouwde context toepassen.

Heeft elke tenant een database nodig?

Niet altijd. Kies op isolatie, herstel, schaal en beheercapaciteit.

Vervangt databasescheiding autorisatie?

Nee. Applicatie en beheer blijven rechten en gecontroleerde credentials nodig hebben.

Hoe testen we isolatie?

Met geautoriseerde testaccounts en controles op lezen, schrijven, export, taken en privileges.

Wat is een noisy neighbour?

Een tenant gebruikt gedeelde capaciteit en vertraagt anderen, ook zonder datalek.

Maak van uw idee een uitvoerbare scope

Deel het gebruikerspad, de koppelingen en de voorwaarden voor lancering. We kunnen een raming met aannames en uitsluitingen opstellen.

Bekijk de dienstverlening →