Multi-tenant vanaf dag één

Vrijwel elke SaaS-herontwikkeling die we zijn geroepen te redden, gaat terug op dezelfde drie woorden die het oorspronkelijke team al in de eerste maand uitsprak: « dat bouwen we later in ». Multi-tenancy, rolgebaseerde toegangscontrole, echte facturatie. Het lijken dingen die je eraan toevoegt zodra je klanten hebt. Het is net omgekeerd — ze zijn de vorm zelf van het gebouw, en je kunt het fundament niet veranderen wanneer de muren eenmaal staan zonder alles af te breken.

We hebben platforms gebouwd die vandaag in meer dan 40 landen draaien op één enkele codebasis. De reden die dat mogelijk heeft gemaakt, is even saai als eensgezind: tenancy, toegang en facturatie werden vanaf dag één beslist, vóór de eerste functie. Zo zien die beslissingen eruit, en dit kost het om ze uit te stellen.

01Waarom teams het ontwijken (en waarom dat een valstrik is)

De druk is reëel. Je hebt één pilootklant, volgende week een demo, en een backlog vol functies die er echt als het product uitzien. Multi-tenancy is onzichtbaar voor die eerste klant — hij kan het niet zien, dus lijkt het op overbodige opsmuk. Het team bouwt dus « voorlopig » een single-tenant-applicatie en belooft die later te veralgemenen.

De valstrik is dat « voorlopig single-tenant » één aanname in elke laag laat lekken: dat er precies één organisatie ter wereld bestaat. Die aanname belandt uiteindelijk in je queries, je authenticatie, je caches, je achtergrondtaken, je bestandspaden. Ze er later weer uithalen is geen refactoring — het is een herontwikkeling, want de aanname zit niet op één plek, ze zit overal.

02De tenant is de eerste kolom

Onze regel is eenvoudig: elke rij die aan een klant toebehoort, draagt een tenant_id, en er bestaat geen codepad dat een query kan uitvoeren zonder die. Geen conventie die mensen zich herinneren — een beperking die de database en het framework afdwingen, zodat het vergeten ervan onmogelijk wordt in plaats van louter af te raden.

De zuiverste variant die we gebruiken, steunt op de database zelf. Row-level-security-policy's betekenen dat de grens tussen tenants één laag onder de applicatiecode wordt afgedwongen, daar waar een ORM-bug of een vergeten WHERE-clausule de data van de ene klant niet naar een andere kan laten lekken. De applicatie stelt de huidige tenant in op de verbinding; de database weigert iets anders terug te geven.

-- the boundary lives below the app, not inside it
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- app sets the tenant per request; a forgotten WHERE
-- clause now returns zero rows instead of someone else's data
SET app.tenant = 'a91f…';
SELECT * FROM orders;   -- only this tenant's orders, always

Deze ene beslissing haalt een hele categorie catastrofale bugs — het datalek tussen tenants — voorgoed van je zorgenlijst. Het zijn de twee dagen werk met de grootste hefboomwerking van het hele project.

03RBAC is geen instellingenpagina

Het tweede « later » dat in een herontwikkeling verandert, is de toegangscontrole. Teams gaan live met een impliciete wereld van twee rollen — admin en gebruiker — hard gecodeerd in if-instructies, verspreid over de hele codebasis. Dan vraagt een grootzakelijke klant om een rol « alleen facturatie », of een « alleen-lezen auditor », en ontdek je permissielogica op tweehonderd plekken.

We modelleren permissies van meet af aan als data: de rollen, de permissies en de toewijzingen daartussen leven in tabellen, en elke beveiligde actie stelt één enkele centrale autoriteit een vraag: « mag deze actor dit doen op deze resource, binnen deze tenant? ». Een rol toevoegen wordt een regel, geen release. Dat is wat een platform in staat stelt ja te zeggen tegen het organigram van de grootzakelijke klant zonder de applicatiecode aan te raken.

• Permissies zijn werkwoorden op resources — invoice:read, invoice:void — geen vage niveaus zoals « manager ».
• Rollen zijn bundels van permissies die een tenant kan samenstellen, zodat twee klanten verschillende dingen kunnen verstaan onder « admin ».
• Elke controle loopt door één poort. Autorisatielogica op één plek is auditeerbaar; verspreide if-instructies zijn een risico.

04Facturatie is een product, geen leidingwerk

Facturatie is waar « dat voegen we later toe » het meeste pijn doet, want tegen de tijd dat je het toevoegt, heb je klanten met handdrukafspraken, inconsistente data over wie wat verschuldigd is, en geen zuiver concept van een abonnement. Facturatie inhalen betekent geld afstemmen, en dat is de enige plek waar een bug niet alleen vervelend is — het is een terugbetaling, een geschil of een nalevingsprobleem.

We ontwerpen het facturatiemodel samen met het tenantmodel: plannen, abonnementen, verbruik, facturen, en de levenscyclus die ze verbindt. Zelfs als de eerste klanten handmatig worden gefactureerd, is het datamodel er vanaf dag één, zodat het later inschakelen van selfserviceplannen een functie is, geen migratie van je volledige omzetgeschiedenis.

05Veertig landen, één codebasis

Meer dan 40 landen bereiken klinkt als een schaalverhaal. In werkelijkheid is het een configuratieverhaal. Het platform heeft geen landspecifieke codetakken — het heeft een tenantmodel dat rijk genoeg is om wat per regio verschilt als data uit te drukken: valuta, belastingregels, taal, datumformaten, de juridische vermeldingen op een factuur.

Wanneer de grens tussen « code » en « configuratie » vanaf dag één correct wordt getrokken, is een nieuw land een inwerktaak, geen engineeringproject. Wordt ze verkeerd getrokken, dan is elke nieuwe markt een fork, en binnen een jaar onderhoud je een dozijn subtiel verschillende versies van dezelfde applicatie en lever je elke correctie een dozijn keer op. Het resultaat « één codebasis » vloeit voort uit beslissingen genomen vóór de eerste klant.

06De checklist voor dag één

Als je dit kwartaal een SaaS-platform start, zijn dit de beslissingen die je moet nemen voordat je ook maar één functie schrijft — niet omdat ze dringend zijn, maar omdat ze onomkeerbaar zijn:

1. Zet een tenant_id op alles en dwing het onder de applicatie af. Row-level security of een equivalent. Maak een query tussen tenants onmogelijk, niet onwaarschijnlijk.
2. Modelleer permissies als data. Rollen en toewijzingen in tabellen, één centrale autorisatiepoort. Een rol toevoegen zou een regel moeten zijn.
3. Bouw het facturatie-datamodel vroeg. Plannen, abonnementen, facturen — zelfs als je in het begin handmatig factureert. Haal geld niet achteraf in.
4. Scheid code van configuratie. Alles wat per klant of regio varieert, is data. Land nummer 41 zou een inwerkformulier moeten zijn.
5. Schrijf het tenant-provisioningpad eerst. Een nieuwe tenant netjes aanmaken, met zinvolle standaardwaarden, is je meest uitgevoerde operatie. Automatiseer haar vanaf dag één.

Niets daarvan is exotisch. Het zijn een paar weken discipline aan het begin in ruil voor het nooit hoeven doen van de herontwikkeling. De teams die 40 landen op één codebasis bereiken, hebben geen geluk gehad — ze hebben simpelweg geweigerd « later » te zeggen over de drie dingen die zich niet later laten toevoegen.