Multi-tenancy is een architectuur waarbij één applicatie, vanuit één codebase, meerdere klanten ("tenants") bedient, terwijl de data van elke klant strikt gescheiden blijft. In plaats van voor elke klant een nieuwe kopie van de software uit te rollen, bedient één deployment iedereen, onzichtbaar voor elke klant afzonderlijk.
Hoe multi-tenancy typisch gebouwd wordt
Er zijn een paar gangbare aanpakken, elk met eigen afwegingen:
Één database met een tenant-identificatie op elke relevante tabel, de eenvoudigste en meest gebruikte aanpak
Aparte database-schema's per tenant, voor sterkere scheiding met wat meer operationele overhead
Volledig gescheiden databases per tenant, de sterkste scheiding, meestal voorbehouden voor klanten met strikte compliance-eisen
Waarvoor multi-tenancy goed is
Multi-tenancy vormt de ruggengraat van de meeste SaaS-producten. Het laat je toe één applicatie te onderhouden en te verbeteren terwijl je veel klanten bedient, in plaats van een aparte installatie per klant te onderhouden, wat vanaf een handvol klanten onbeheersbaar wordt.
Waar je op moet letten
De scheiding van data moet waterdicht zijn; een fout waarbij de ene klant data van een andere ziet, is het slechtst denkbare scenario bij deze architectuur. Daarnaast moet je rekening houden met aanpassingen per klant, schaalbaarheid naarmate het aantal klanten groeit, en hoe de data van een klant geëxporteerd of verwijderd wordt wanneer die vertrekt.
Vulpo en Multi-tenancy
We bouwen SaaS-platformen en back-officesystemen die meerdere klanten bedienen vanuit één codebase. Multi-tenancy is iets waar we vanaf de start van een Laravel-project rekening mee houden, niet iets dat er achteraf bij geplakt wordt zodra het een probleem wordt.
