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

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.
Explore more design patterns and system architectures
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 KontaktMulti-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.
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.
tenant_id. For schema-per-tenant: dynamisk forbindelsesrouting med connection pool management. For database-per-tenant: provisioneringsautomatisering med Terraform/Pulumiacme.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.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.| Lag | Teknologier |
|---|---|
| Compute | Node.js (NestJS), Python (FastAPI), containerized på ECS Fargate eller Kubernetes |
| Data | PostgreSQL med RLS, Redis (tenant-scoped), S3 (tenant-partitionerede buckets) |
| Identitet | Clerk, Auth0 eller Okta med tenant-scoped organisationer |
| Fakturering | Stripe Connect (markedspladsmodel), Stripe Billing (målte abonnementer) |
| Observability | Datadog med tenant-dimensions tags, struktureret logging med tenant_id på hver post |
| Brug når | Undgå når |
|---|---|
| Du bygger en B2B-platform, der betjener 10+ kunder fra delt infrastruktur | Hver kunde kræver fuldt dedikeret infrastruktur (compliance/kontraktuelt) |
| Du har brug for white-label branding, brugerdefinerede domæner og feature-kontrol pr. tenant | Du 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. tenant | Produktet er en forbruger-app med bruger-niveau konti, ikke organisations-niveau tenants |
| Du ønsker én deployment pipeline, én monitoring stack, én on-call rotation | Tenants har fundamentalt forskellige skemaer eller forretningslogik (ikke kun konfiguration) |
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.
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.
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.