MicrocosmWorksInnovere og Arkitektere Digitale Kosmos
OmKontakt
MicrocosmWorksInnoverer og arkitekterer digitale kosmos

Leverer IT-løsninger, der betyder noget. Vi brænder for teknologi, sikkerhed og at hjælpe virksomheder med at vokse gennem pålidelig, innovativ IT-infrastruktur.

[email protected]
+91 7011868196
New Delhi, India

AI Væksthub

AI HubStartup-innovationVirksomhedsaccelerator

Løsninger

Alle løsningerSundhed & Fitness AppsAI VideoplatformAI Agentudvikling

Ressourcer

IndsigterIndustri GuiderBrugssag BlueprintsArkitektur MønstreCase Studier

Virksomhed

Om OsKontaktVores Arbejde

Tjenester

Digital RådgivningCloud InfrastrukturSaaS UdviklingAI UdviklingVideo Teknologi
ERP UdviklingZoho TilpasningOdoo UdviklingSalesforce IntegrationTilpasset CRM Udvikling
QuickBooks IntegrationIoT LøsningerBlockchain Udvikling
Cybersikkerhed RådgivningIT-support - L3

© 2026 MicrocosmWorks. Alle rettigheder forbeholdes.

PrivatlivspolitikServicevilkår
Tilbage til arkitekturmønstre
ApplicationAdvanced

Multi-Tenant SaaS-arkitektur

Én kodebase, hundredvis af tenants, ingen datalækage — fundamentet for enhver skalerbar SaaS-virksomhed.

June 22, 2026
|
3 topics covered
Diskuter denne arkitektur
multi-tenant-saas-architecture.webp
Application
Category
Advanced
Complexity
Sundhedssektor, EdTech
Industries
3+
Technologies

Når du har brug for dette

Du bygger en platform, der betjener flere kunder fra en enkelt udrulning. Hver kunde forventer isolerede data, brandede oplevelser og fakturering pr. tenant — men du har ikke råd til at køre separat infrastruktur for hver enkelt. Du har brug for økonomien ved delt infrastruktur med isolationsgarantierne fra dedikerede systemer. Dette er den grundlæggende spænding i SaaS-arkitektur, og at vælge den forkerte isolationsmodel tidligt er en af de dyreste fejl i platformudvikling.

Related Architecture Patterns

Explore more design patterns and system architectures

event-driven-microservices.webp
Application

Begivenhedsdrevne Mikroservices

Frakobl alt. Lad services kommunikere gennem begivenheder, ikke forventninger om hinandens oppetid.

EnterpriseView
ai-ml-pipeline-architecture.webp

Har du brug for hjælp til at implementere denne arkitektur?

Vores arkitekter kan hjælpe dig med at designe og bygge systemer ved hjælp af dette mønster til dine specifikke krav.

Kom i Kontakt

Mønsteroverblik

Multi-tenant SaaS-arkitektur giver logisk eller fysisk adskillelse mellem tenants, samtidig med at underliggende compute-, storage- og netværksressourcer deles. Mønsteret omfatter tenant-provisionering, dataisolering, funktionsstyring, faktureringsmåling og white-label-tilpasning. Den centrale designbeslutning er isolationsmodellen: delt database med RLS (row-level security), schema-per-tenant eller database-per-tenant. Hver model afvejer isolationsstyrke mod operationel kompleksitet og omkostningseffektivitet.

Referencearkitektur

Systemet er organiseret i tre lag. Den tenant-aware gateway håndterer autentificering, tenant-opløsning (via subdomain, JWT-claim eller API key) og anmodningsrouting. Applikationslaget opererer udelukkende inden for tenant-kontekst — hver forespørgsel, hver cache-nøgle, hver kø-besked er afgrænset til den fundne tenant. Datalaget håndhæver isolation på storage-niveau gennem RLS-politikker (row-level security policies), connection pooling pr. tenant og krypteret-at-rest partitionering.

Kernekomponenter
  • Tenant Management Service: Håndterer provisionering, onboarding-workflows, brugerdefineret domænekortlægning, tema-/branding-konfiguration og feature flags pr. tenant. Eksponerer en intern API for tenant lifecycle events (oprettet, suspenderet, slettet)
  • Tenant Context Propagator: Middleware, der løser tenant-identiteten fra anmodningen (subdomain, JWT, header) og injicerer tenant-kontekst i hvert downstream-kald — databaseforbindelser, cache-nøgler, kø-beskeder, log-indgange
  • Data Isolation Engine: Implementerer den valgte isolationsmodel. For RLS: PostgreSQL-politikker, der filtrerer hver forespørgsel efter tenant_id. For schema-per-tenant: dynamisk forbindelsesrouting med connection pool management. For database-per-tenant: provisioneringsautomatisering med Terraform/Pulumi
  • Billing & Metering Service: Event-driven forbrugssporing med aggregering pr. tenant. Integreres med Stripe Connect eller brugerdefinerede billing engines. Understøtter flere prismodeller (pr. bruger, forbrugsbaseret, trinvist, hybrid)

Designbeslutninger og afvejninger

RLS vs. Schema-per-Tenant vs. Database-per-Tenant
MW bruger som standard RLS (delt database, row-level security) for de fleste SaaS-produkter. Det er det enkleste at drive — én migrationssti, én connection pool, én backup-strategi. Schema-per-tenant giver mening, når tenants har brug for brugerdefinerede skemaudvidelser (sjældent), eller når lovgivningsmæssige krav kræver beviselig isolation. Database-per-tenant er reserveret til enterprise-aftaler, hvor kunden kontraktmæssigt kræver dedikeret infrastruktur. Vi har leveret alle tre — valget afhænger af jeres compliance-position og antal tenants.
Subdomain vs. Path-Baseret Tenant Resolution
Subdomæner (acme.yourapp.com) er renere for white-label-produkter og tillader TLS-certifikater pr. tenant. Path-baseret (yourapp.com/acme/) er enklere at implementere og undgår wildcard DNS-kompleksitet. MW anbefaler subdomain-opløsning for B2B SaaS med white-label-krav, path-baseret for interne multi-tenant-værktøjer.
Delte Feature Flags vs. Konfiguration pr. Tenant
Vi bruger et to-lags feature flag-system: globale flags styrer udrulning på tværs af platformen, tenant-niveau overskrivninger lader dig aktivere beta-features for specifikke kunder eller deaktivere features for tenants på lavere abonnementsplaner. Edge Config eller LaunchDarkly understøtter dette med sub-millisekund aflæsninger.
Tenant-Aware Caching
Hver cache-nøgle skal være afgrænset til tenant_id. Dette lyder indlysende, men cache-nøglekollisioner på tværs af tenants er en af de mest almindelige multi-tenant-fejl. Vi håndhæver dette gennem en cache key factory, der automatisk foranstiller tenant-konteksten.

Teknologivalg

LagTeknologier
ComputeNode.js (NestJS), Python (FastAPI), containerized på ECS Fargate eller Kubernetes
DataPostgreSQL med RLS, Redis (tenant-scoped), S3 (tenant-partitionerede buckets)
IdentitetClerk, Auth0 eller Okta med tenant-scoped organisationer
FaktureringStripe Connect (markedspladsmodel), Stripe Billing (målte abonnementer)
ObservabilityDatadog med tenant-dimensions tags, struktureret logging med tenant_id på hver post

Hvornår skal det bruges / Hvornår skal det undgås

Brug nårUndgå når
Du bygger en B2B-platform, der betjener 10+ kunder fra delt infrastrukturHver kunde kræver fuldt dedikeret infrastruktur (compliance/kontraktuelt)
Du har brug for white-label branding, brugerdefinerede domæner og feature-kontrol pr. tenantDu har færre end 3 kunder — en enklere udrulning pr. kunde kan være tilstrækkelig
Forbrugsbaseret eller trinvis prissætning kræver måling pr. tenantProduktet er en forbruger-app med bruger-niveau konti, ikke organisations-niveau tenants
Du ønsker én deployment pipeline, én monitoring stack, én on-call rotationTenants har fundamentalt forskellige skemaer eller forretningslogik (ikke kun konfiguration)

Vores tilgang

MW behandler multi-tenancy som en tværgående bekymring, ikke en funktion. Vi implementerer tenant-kontekstpropagation på middleware-niveau, så applikationskoden aldrig manuelt filtrerer efter tenant — det håndhæves af frameworket. Vores RLS-implementeringer inkluderer automatiserede testsuiter, der forsøger cross-tenant dataadgang ved hver CI-kørsel. Vi har bygget multi-tenant-platforme, der betjener 500+ tenants på delt infrastruktur uden datalækagehændelser, og vi har migreret single-tenant-monolitter til multi-tenant-arkitekturer ved hjælp af strangler fig-mønsteret.

Relaterede blueprints

  • Multi-Tenant Wellness Coaching SaaS — RLS-isolation med white-label branding til coaching-virksomheder
  • AI-Drevet Personlig Læringsplatform — Multi-tenant EdTech med indholdsbiblioteker pr. tenant
  • Event Management & Ticketing Platform — Tenant pr. arrangør med real-time billetudstedelse
  • Multi-Tenant Billing & Subscription Engine — Billing-rygraden for multi-tenant-platforme

Relaterede casestudier

  • VR Training Multi-Tenant SaaS — Multi-tenant-platform med tenant-scoped VR-indhold og analyser
  • AI Chat Platform — Multi-model chat SaaS med API key management pr. tenant og GDPR-overholdelse
Related Technologies
SaaS-udviklingCloud-løsningerAI-udvikling
AI / Data

AI/ML Pipeline Arkitektur

Modeller kører ikke sig selv. Den pipeline, der træner, validerer, implementerer og overvåger dine modeller, er det egentlige produkt – modellen er blot ét artefakt.

EnterpriseView
cloud-native-infrastructure.webp
Infrastructure

Cloud-Native Infrastruktur

Infrastruktur, der er versioneret, testet og implementeret som applikationskode — fordi din platform kun er så pålidelig som det, der ligger under den.

EnterpriseView

Ofte stillede spørgsmål

Det optimale valg afhænger af jeres krav til tenant-isolering og skalering. MicrocosmWorks anbefaler typisk en delt-database, separat-skema tilgang for de fleste B2B SaaS-produkter, da den balancerer omkostningseffektivitet med dataisolering, selvom vi implementerer database-per-tenant for kunder i regulerede brancher som sundhedssektoren eller finanssektoren, hvor streng datasegregering er påkrævet. Vores arkitekter evaluerer jeres compliance-behov, forventede antal tenants og forespørgselsmønstre, før de anbefaler den rette tenancy-model.

MicrocosmWorks implementerer lejerspecifik rate limiting, connection pooling med kvoter pr. lejer og ressourceisolation på beregningslaget for at forhindre problemer med støjende naboer. Vi bruger teknikker som vægtet fair køhåndtering og lejerspecifikke caching-lag, så et pludseligt peak fra én kunde ikke fører til forsinkelse for andre. For lejere på virksomhedsniveau kan vi provisionere dedikerede beregningspartitioner, samtidig med at den delte control plane bevares intakt.

MicrocosmWorks tilbyder arkitekturdesign- og implementeringstjenester til konsulentpriser mellem $15-$45/time afhængigt af den krævede kompleksitet og teamets anciennitet. Et typisk multi-tenant SaaS-arkitekturprojekt – der dækker database design, tenant isolation, authentication og deployment pipelines – løber 8-16 uger med et tværfagligt team. Vi afgrænser hvert projekt med en fixed-price discovery-fase, så du har fuld omkostningsoversigt, før du forpligter dig til byggeriet.

MicrocosmWorks bygger automatiserede pipelines til provisionering af lejere, der håndterer skemaoprettelse, DNS-konfiguration, initialisering af feature flags og deployment af seed data inden for få minutter efter en ny tilmelding. Vi bruger infrastructure-as-code-værktøjer som Terraform eller Pulumi kombineret med event-drevne workflows, så hver ny lejer får et fuldt konfigureret miljø uden manuel intervention. Denne tilgang lader vores klienter skalere fra 10 lejere til 10.000 uden at ændre onboarding-processen.

MicrocosmWorks implementerer et konfigurationsdrevet tilpasningslag ved hjælp af feature flags, lejerspecifik metadata og en plugin-arkitektur, der muliggør adfærd pr. lejer uden kodeforgrening. Vi designer udvidelsespunkter i UI-temaer, workflow engine og integrationslagene, så lejere kan have unik branding, forretningsregler og tredjepartsforbindelser – alt sammen styret gennem konfiguration. Dette holder jeres ingeniørteam vedligeholdende en enkelt kodebase, samtidig med at det understøtter forskellige kundekrav.