Multi-tenancy in SaaS: silo, pool of bridge — en de weg ertussen

De duurste beslissing vóór uw eerste klant

In een SaaS-platform is het tenancy-model het punt waar unit economics, securityhouding en engineeringsnelheid samenkomen. Het bepaalt wat elke klant kost om te bedienen, hoe ver een incident zich verspreidt, wat u een auditor kunt toezeggen en hoe pijnlijk elke toekomstige migratie wordt. Teams besteden weken aan de keuze van een frontend-framework en één middag aan het tenancy-model. Die verhouding hoort andersom: frameworks zijn vervangbaar, tenancy-modellen verstenen.

Drie canonieke modellen dekken het speelveld — silo, pool en bridge — en geen ervan is simpelweg het beste. Elk ruilt isolatie in tegen operationele kosten. De nuttige vraag is niet welk model juist is, maar welke afwegingen uw bedrijf zich vandaag kan veroorloven — en hoe duur het later wordt om van gedachten te veranderen.

Silo, pool, bridge — de werkelijke afwegingen

De modellen verschillen in wat ze delen en wat ze toewijzen; elke faalwijze volgt rechtstreeks uit die keuze.

• Silo — elke tenant krijgt dedicated resources, doorgaans een database en vaak ook compute. De sterkste isolatie en het eenvoudigste complianceverhaal — maar een harde kostenbodem per tenant en een vlootprobleem: tweehonderd tenants betekent tweehonderd databases om te migreren, back-uppen, patchen en monitoren.
• Pool — alle tenants delen de infrastructuur, gescheiden door een tenant_id. De marginale kosten per tenant naderen nul, maar isolatie wordt de taak van de applicatie en één slechte query kan iedereen tegelijk vertragen.
• Bridge — gedeelde compute boven gescheiden data (schema of database per tenant), of een gelaagde vloot: pooled infrastructuur voor het standaardplan, dedicated silo's voor gereguleerde of enterprise-tenants.

Onze standaard voor B2B-producten is een pooled model achter een strikte tenancy-abstractie, met silo als geprijsde premiumlaag — nooit als reflex. Dedicated infrastructuur waar niemand voor betaalt, is geen architectuur maar een subsidie.

Isolatie is gelaagde verdediging, geen WHERE-clausule

Een tenant_id-kolom plus discipline van ontwikkelaars is geen isolatiestrategie; één vergeten filter scheidt u van een meldplichtig datalek. Isolatie moet ook standhouden wanneer een ontwikkelaar een fout maakt — dwing haar daarom af op meerdere onafhankelijke lagen.

• Los de tenantcontext één keer op aan de rand — subdomein, token of header — en geef hem door in elk request, elke job en elk event; niets stroomafwaarts leidt hem opnieuw af.
• Maak cross-tenant queries onmogelijk om per ongeluk te schrijven: repositories of query builders die de tenantscope by construction afdwingen, niet per conventie.
• Schakel row-level security in de database in als vangnet: een gemist filter laat de query mislukken in plaats van een dataset te lekken.
• Versleutel gereguleerde velden met sleutels per tenant, zodat offboarding en verwijderverzoeken sleuteloperaties worden in plaats van tabelscans.
• Onderhoud een geautomatiseerde testsuite voor cross-tenant toegang; elke fout daarin is een security-incident, geen bugticket.

Noisy neighbours: een fairnessprobleem, geen capaciteitsprobleem

In een pooled model is capaciteit gedeeld; zonder expliciete fairnessregels bepaalt de grootste tenant de latency van alle anderen, en meer hardware verhoogt alleen het plafond van een oneerlijke scheduler. Meet het verbruik per tenant vanaf dag één: een handvol tenants veroorzaakt het grootste deel van de belasting, en wat u niet toerekent, kunt u niet besturen.

• Handhaaf rate limits en quota per tenant op API-niveau, ingeprijsd in de abonnementen, zodat limieten een commerciële hefboom zijn en geen excuus.
• Begrens de concurrency per tenant in achtergrondqueues — de bulkimport van de één mag nooit de webhooks van de ander vertragen.
• Stel statement-timeouts in en stuur analytische queries naar replica's; het transactionele pad is nooit de plek voor rapportage.
• Op vlootschaal beperken cell-based architectuur en shuffle sharding de blast radius van overbelasting en van foutieve deployments.

Observability die het woord tenant kent

De eerste vraag bij elk SaaS-incident is: wie is geraakt? Als uw telemetrie dat niet binnen enkele seconden kan beantwoorden, heeft u dashboards, geen observability. Maak de tenantidentiteit een eersteklas dimensie in logs, traces en metrics, en ga bewust om met kardinaliteit: volledige detaildiepte in logs en traces, top-N plus aggregaten in metrics.

Definieer SLO's per tenant, minimaal voor uw hoogste tier, en meet het verbruik continu. Dezelfde data beantwoordt supportvragen binnen minuten, voedt usage-based pricing en legt de klanten bloot die u stilletjes met verlies bedient.

Ontwerp de migratie voordat u haar nodig hebt

Met welk model u ook start, ooit moet er een tenant verhuizen: een enterprisecontract eist een silo, of een vloot silo's wordt te duur om te beheren. Het migratiepad is onderdeel van de architectuur, geen bijzaak.

• Houd tenant_id op elke rij, ook in silo-databases — data consolideren zonder die kolom is archeologie.
• Houd de schema's identiek over alle silo's; schema-drift verandert een migratie geruisloos in een herbouw.
• Routeer tenants via een stabiele abstractie die elke tenant aan zijn datalocatie koppelt, zodat die locatie kan veranderen zonder de applicatie aan te passen.
• Oefen de verhuizing: tenant-gescopeerde export, cutover via replicatie, een kort dual-write-venster en een geverifieerde rollback.

Het model waarmee u start, is niet het model waarmee u eindigt. De taak van de architectuur is om van die overstap een gepland project te maken — geen bedrijfsbrede noodsituatie.