Vad är multi-tenant-arkitektur

Multi-tenant-arkitektur innebär att en och samma körande applikation betjänar många kunder, kallade tenants, samtidigt som varje tenants data hålls separat. Det är standardgrunden för SaaS-produkter eftersom alla kunder delar samma kod och infrastruktur, vilket håller driftkostnaderna låga. Designarbetet ligger i att isolera tenants från varandra.

Vad är en tenant

En tenant är ett kundkonto som äger sina egna användare och sin egen data, till exempel ett företag som använder din produkt. Anställda hos tenant A får aldrig se data från tenant B, även om båda använder samma applikation och ofta samma databas.

Hur skiljer det sig från single-tenant

I en single-tenant-uppsättning får varje kund sin egen driftsättning. Det ger stark isolering och enkel kundanpassning, men det multiplicerar arbetet: varje uppgradering, säkerhetskopiering och incident upprepas per kund.

Vilka databasmodeller finns det

Team väljer vanligtvis ett av tre alternativ:

• Delad databas, delade tabeller. Varje rad innehåller ett tenant-ID. Det är det billigaste och enklaste att skala, och det kräver att varje fråga filtrerar korrekt.
• Delad databas, schema per tenant. Varje tenant får ett eget schema. Isoleringen är starkare och migreringar blir tyngre i takt med att antalet tenants växer.
• Databas per tenant. Den starkaste isoleringen och den högsta kostnaden, används ofta för stora eller reglerade kunder.

Många produkter börjar med delade tabeller och flyttar senare stora kunder till en egen databas.

Hur håller du tenants isolerade

Tillämpa isolering på mer än ett ställe. Lägg tenant-ID i varje tabell och varje frågeväg, och lägg till kontroller på databasnivå som row level security, så att ett missat filter i applikationskoden inte läcker data. Testa det explicit: skriv tester som försöker läsa en annan tenants data och förväntar sig att det misslyckas. En läcka mellan tenants är bland de mest skadliga buggar en SaaS-produkt kan ha.

Vad är problemet med störande grannar

När tenants delar resurser kan en resurskrävande tenant sakta ner de andra. Planera för det med rate limits, kvoter per tenant, bakgrundsjobb-köer med rättvis schemaläggning och övervakning som visar belastning per tenant. Att flytta en tung kund till dedikerade resurser är en vanlig åtgärd.

Vad innebär det för regelefterlevnad

Delad infrastruktur väcker frågor vid säkerhetsgranskningar. Större kunder frågar ofta var deras data lagras, hur den är separerad och vem som kan komma åt den. Besluta tidigt om du kan erbjuda regional hosting, till exempel EU-datahemvist, eller en dedikerad driftsättning för kunder som kräver det. Att i efterhand bygga in det i en design som är byggd kring delade tabeller kräver verklig ansträngning.

Vad detta innebär för ditt ingenjörsteam

Tenancy är svårt att ändra när data väl finns, så beslutet förtjänar en senior ingenjörs tid från start. AI-kodningsagenter kan generera frågor snabbt, och de glömmer gärna ett tenant-filter, så isoleringstester och kontroller på databasnivå spelar större roll när agenter skriver kod. Se hur du granskar AI-genererad kod för de granskningsvanor som fångar detta.

Backend-plattformar som Supabase erbjuder row level security som passar delade tabeller. Vår granskning placerar kandidater i en verklig kodbas under två sextio minuter långa sessioner, en med AI-verktyg avstängda och en med deras egna agenter aktiverade. För att lägga till senior kapacitet i ett SaaS-team, se backend-ingenjörer, från €5 600 i månaden för en heltidsanställd ingenjör.

Korta svar