Multi-tenancy i SaaS: silo, pool eller bridge — och vägen däremellan

Det dyraste beslutet före din första kund

I en SaaS-plattform är tenancy-modellen punkten där enhetsekonomi, säkerhetsnivå och utvecklingstakt korsas. Den avgör vad varje kund kostar att betjäna, hur långt en incident sprider sig, vad du kan lova en revisor och hur smärtsam varje framtida migrering blir. Team lägger veckor på att välja frontend-ramverk och en eftermiddag på tenancy-modellen. Proportionerna borde vara omvända: ramverk går att byta ut, tenancy-modeller stelnar.

Tre kanoniska modeller täcker fältet — silo, pool och bridge — och ingen är helt enkelt bäst. Var och en byter isolering mot driftskostnad. Den användbara frågan är inte vilken modell som är rätt, utan vilka avvägningar din verksamhet har råd med i dag — och hur dyrt det blir att ändra sig senare.

Silo, pool, bridge — de faktiska avvägningarna

Modellerna skiljer sig i vad de delar och vad de dedikerar; varje felläge följer direkt av det valet.

• Silo — varje tenant får dedikerade resurser, vanligtvis en databas och ofta även compute. Starkast isolering och den enklaste compliance-berättelsen — men ett hårt kostnadsgolv per tenant och ett flottproblem: tvåhundra tenants innebär tvåhundra databaser att migrera, säkerhetskopiera, patcha och övervaka.
• Pool — alla tenants delar infrastruktur, åtskilda av ett tenant_id. Marginalkostnaden per tenant närmar sig noll, men isoleringen blir applikationens ansvar och en enda dålig query kan försämra upplevelsen för alla samtidigt.
• Bridge — delad compute ovanpå separerad data (schema eller databas per tenant), eller en nivåindelad flotta: poolad infrastruktur för standardplanen, dedikerade silor för reglerade tenants eller enterprise-kunder.

Vår standard för B2B-produkter är en poolad modell bakom en strikt tenancy-abstraktion, där silo säljs som ett prissatt premiumtier — inte införs av gammal vana. Dedikerad infrastruktur som ingen betalar för är inte arkitektur, utan en subvention.

Isolering är försvar i lager, inte en WHERE-sats

En tenant_id-kolumn plus utvecklardisciplin är ingen isoleringsstrategi; ett enda glömt filter skiljer dig från en anmälningspliktig dataläcka. Isoleringen måste hålla även när en utvecklare gör fel — tvinga därför fram den i flera oberoende lager.

• Lös upp tenant-kontexten en enda gång i kanten — subdomän, token eller header — och för den vidare genom varje request, jobb och event; inget längre ned ska härleda den på nytt.
• Gör cross-tenant-queries omöjliga att skriva av misstag: repositories eller query builders som kräver tenant-scope genom sin konstruktion, inte genom konvention.
• Aktivera row-level security i databasen som ett skyddsnät: ett missat filter får queryn att misslyckas i stället för att läcka ett dataset.
• Kryptera reglerade fält med nycklar per tenant, så att offboarding och raderingsbegäranden blir nyckeloperationer i stället för tabellskanningar.
• Underhåll en automatiserad testsvit för cross-tenant-åtkomst; varje fel där är en säkerhetsincident, inte ett buggärende.

Noisy neighbours: ett rättviseproblem, inte ett kapacitetsproblem

I en poolad modell är kapaciteten delad; utan uttryckliga rättviseregler sätter den största tenanten latensen för alla andra, och mer hårdvara höjer bara taket för en orättvis schemaläggare. Mät förbrukningen per tenant från dag ett: en handfull tenants står för merparten av lasten, och det du inte attribuerar kan du inte styra.

• Inför rate limits och kvoter per tenant i API-lagret, inprisade i planerna, så att gränserna blir en kommersiell hävstång och inte en ursäkt.
• Begränsa samtidigheten per tenant i bakgrundsköer — en tenants bulkimport får aldrig fördröja en annans webhooks.
• Sätt statement-timeouts och styr analytiska queries till repliker; den transaktionella vägen är aldrig platsen för rapportering.
• På flottnivå begränsar cellbaserad arkitektur och shuffle sharding felspridningen från både överlast och felaktiga deployer.

Observability som kan säga ordet tenant

Den första frågan vid varje SaaS-incident är: vem är drabbad? Om din telemetri inte kan svara på det inom sekunder har du dashboards, inte observability. Gör tenant-identiteten till en förstklassig dimension i loggar, traces och metrics, och hantera kardinaliteten medvetet: full upplösning i loggar och traces, topp-N plus aggregat i metrics.

Definiera SLO:er per tenant åtminstone för ditt högsta tier och mät förbrukningen kontinuerligt. Samma data besvarar supportfrågor på minuter, driver användningsbaserad prissättning och avslöjar de kunder du i tysthet betjänar med förlust.

Designa migreringen innan du behöver den

Oavsett vilken modell du lanserar med kommer någon tenant förr eller senare att behöva flytta: ett enterprise-avtal kräver en silo, eller så blir en flotta av silor för dyr att driva. Migreringsvägen är en del av arkitekturen, inte en eftertanke.

• Behåll tenant_id på varje rad även i silo-databaser — att konsolidera data utan den är arkeologi.
• Håll schemana identiska över alla silor; schemadrift förvandlar i tysthet en migrering till en omskrivning.
• Routa tenants genom en stabil abstraktion som kopplar varje tenant till dess datahem, så att platsen kan ändras utan ändringar i applikationen.
• Repetera flytten: tenant-avgränsad export, övergång via replikering, ett kort dual write-fönster och en verifierad rollback.

Modellen du lanserar med blir inte den du avslutar med. Arkitekturens uppgift är att göra det bytet till ett planerat projekt — inte en företagsövergripande nödsituation.