\nHeavy per-tenant customization of schema?<\/td>\n Revisit product design first \u2014 then B\/C<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nRule of thumb: start with Method A unless compliance or enterprise sales force you higher.<\/strong> You can always offer a dedicated database later for a premium tier; starting on Method C for every free trial customer is how teams drown in ops work.<\/p>\nAlso decide early what \u201cdelete tenant\u201d means: soft-suspend, hard purge, or export-then-delete. Method A makes purge a careful multi-table cleanup. Methods B and C make drop-schema \/ drop-database tempting \u2014 still verify backups and legal retention first.<\/p>\n
Alkademy Press made the Method A choice deliberately \u2014 covered next after tenant resolution.<\/p>\n
Resolving Tenant Context on Every Request<\/h2>\n Regardless of database strategy, every request must answer: which tenant is this?<\/em> Common signals:<\/p>\n\nExplicit header<\/strong> \u2014 e.g. X-Tenant-Id<\/code> from a logged-in SPA<\/li>\nSubdomain<\/strong> \u2014 northgate.yourproduct.com<\/code><\/li>\nCustom domain<\/strong> \u2014 journal.university.edu<\/code> mapped to a tenant<\/li>\nJWT \/ session claim<\/strong> \u2014 tenant_id<\/code> embedded at login<\/li>\nPath<\/strong> \u2014 \/t\/{slug}\/...<\/code> (less common for APIs)<\/li>\n<\/ol>\nProduction systems often support several signals with a clear priority order<\/strong>. The browser app may always send a header, while public journal sites resolve via custom domain. Auth still carries a claim so tokens cannot wander across organisations.<\/p>\n\nRequest \u2192 resolve tenant \u2192 attach context \u2192 query with id + tenantId<\/figcaption><\/figure>\nCase Study: Alkademy Press<\/h2>\n Alkademy Press<\/strong> is a multi-tenant Journal Management System<\/strong> for academic publishing. University presses, research institutes, and consortia run submissions, peer review, editorial workflows, and public journal websites from one SaaS product \u2014 instead of installing and maintaining a separate journal stack per organisation.<\/p>\nThat product shape is a textbook multi-tenancy problem: dozens or hundreds of organisations, nearly identical workflows, strong expectations that Press A never sees Press B\u2019s manuscripts, and a need for self-serve branding (logos, colors, custom domains) without forking the codebase.<\/p>\n
Tenant hierarchy in Press:<\/p>\n\nPlatform \u2192 Tenant (organisation) \u2192 Journal(s) \u2192 submissions, reviews, members<\/figcaption><\/figure>\n\nPlatform<\/strong> \u2014 Alkademy operators; shared website templates; feature flags; tenant provisioning<\/li>\nTenant<\/strong> \u2014 the publishing organisation (name, slug, plan, status, Stripe customer)<\/li>\nJournal<\/strong> \u2014 one or more journals per tenant, with branding, APC settings, optional custom domain<\/li>\nWorkflow data<\/strong> \u2014 members, submissions, review rounds, volumes\/issues, audit logs \u2014 all tenant-scoped<\/li>\n<\/ul>\nUsers are unique per tenant (tenantId + email<\/code>), so the same person can belong to different organisations with separate memberships and roles. Roles span platform admin down through tenant admin, editor, reviewer, and author.<\/p>\nWhat Method Alkademy Press Uses<\/h2>\n Alkademy Press uses Method A: shared PostgreSQL database, shared schema, row-level multi-tenancy via a tenantId<\/code> discriminator.<\/strong><\/p>\nThat was an explicit architecture decision early in the product: one database, tenant isolation enforced by tagging domain rows and filtering in application services \u2014 not schema-per-tenant, not database-per-tenant, and not Postgres Row-Level Security as the primary control.<\/p>\n
Why that fit Press:<\/p>\n
\nEvery organisation runs the same journal\/editorial domain model<\/strong><\/li>\nSaaS economics matter \u2014 many presses on shared infra<\/li>\n A NestJS + Prisma stack stays simple when there is one schema to migrate<\/li>\n Plan limits, branding, and custom domains provide differentiation without siloed databases<\/li>\n<\/ul>\nTenant resolution in Press<\/h3>\n Incoming requests resolve tenant context in this priority order:<\/p>\n
\nX-Tenant-Id<\/code> header (highest) \u2014 the React app sends the logged-in user\u2019s tenant UUID on API calls<\/li>\nPlatform subdomain<\/strong> \u2014 host under the product domain suffix<\/li>\nCustom domain<\/strong> \u2014 look up the journal\u2019s configured domain, then attach that journal\u2019s tenantId<\/code><\/li>\nJWT claim tenant_id<\/code><\/strong> \u2014 backfilled during authentication if still unset<\/li>\n<\/ol>\nConceptual middleware (simplified):<\/p>\n
async use(req, _res, next) {\n const headerTenantId = req.headers['x-tenant-id'];\n if (headerTenantId) {\n req.tenantId = headerTenantId;\n return next();\n }\n\n const host = (req.headers.host ?? '').split(':')[0];\n\n if (host.endsWith(domainSuffix)) {\n const subdomain = host.slice(0, -domainSuffix.length);\n if (subdomain && !subdomain.includes('.')) {\n req.tenantId = subdomain;\n return next();\n }\n }\n\n const journal = await prisma.journal.findFirst({\n where: { customDomain: host },\n select: { tenantId: true },\n });\n if (journal) {\n req.tenantId = journal.tenantId;\n return next();\n }\n\n \/\/ JWT strategy may still attach tenant_id after auth\n next();\n}\n<\/code><\/pre>\nOn the client, the access token and tenant id travel together:<\/p>\n
api.interceptors.request.use((config) => {\n const token = authStore.accessToken;\n const tenantId = authStore.user?.tenantId;\n if (token) config.headers['Authorization'] = `Bearer ${token}`;\n if (tenantId) config.headers['X-Tenant-Id'] = tenantId;\n return config;\n});\n<\/code><\/pre>\nIsolation in practice<\/h3>\n Controllers pass req.tenantId<\/code> into services. Services do not look up a submission \u201cby id alone\u201d \u2014 they look it up by id and tenant<\/strong>. That pattern repeats across journals, members, reviews, and billing usage events.<\/p>\nconst submission = await prisma.submission.findFirst({\n where: { id, tenantId },\n});\nif (!submission) throw new NotFoundException('Submission', id);\n<\/code><\/pre>\nReturning \u201cnot found\u201d (instead of \u201cforbidden\u201d) for cross-tenant ids avoids leaking whether a resource exists in another organisation.<\/p>\n
What is shared vs isolated in Press<\/h3>\n \n\n\nResource<\/th>\n Shared or isolated?<\/th>\n<\/tr>\n<\/thead>\n \n\nPostgreSQL database & schema<\/td>\n Shared<\/td>\n<\/tr>\n \nJournals, submissions, reviews, audit logs<\/td>\n Isolated by tenantId<\/code><\/td>\n<\/tr>\n\nUsers & roles<\/td>\n Isolated per tenant<\/td>\n<\/tr>\n \nStripe billing & plan meters<\/td>\n Per tenant<\/td>\n<\/tr>\n \nWebsite templates (catalog)<\/td>\n Shared platform catalog; adopted per journal<\/td>\n<\/tr>\n \nApp servers, Redis queues, object storage stack<\/td>\n Shared infra; logical isolation in app<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSuspended tenants are blocked at login when status is not active \u2014 another tenancy control that sits above raw SQL filters.<\/p>\n
Multi-Tenant Features in Alkademy Press<\/h2>\n Row-level tenancy is the foundation. Product features built on top of it include:<\/p>\n
\nOrganisation provisioning<\/strong> \u2014 platform admins create tenants (name, slug, plan) and optional tenant admins.<\/li>\nRBAC<\/strong> \u2014 platform_admin, tenant admins, editors, reviewers, authors \u2014 claims stay within the active tenant.<\/li>\nPer-journal branding<\/strong> \u2014 logos, banners, color themes, and publishable website templates.<\/li>\nRouting flexibility<\/strong> \u2014 subdomain-style hosts, custom domains for public journal sites, and path\/slug public URLs.<\/li>\nPlan limits<\/strong> \u2014 free \/ starter \/ pro \/ enterprise meters (journals, submissions per month, AI screenings, storage).<\/li>\nImpersonation<\/strong> \u2014 platform support can open a session as a user inside a target tenant when needed.<\/li>\nFeature flags & announcements<\/strong> \u2014 global defaults with per-tenant overrides or targeting.<\/li>\nAudit trail<\/strong> \u2014 tenant-scoped audit logs for editorial and admin actions.<\/li>\n<\/ol>\nThat mix is typical of healthy Method A products: shared core, tenant-scoped data, tenant-visible customization at the edges.<\/strong><\/p>\nCommon Pitfalls and How to Harden<\/h2>\n Whether you build the next Alkademy Press or a different SaaS, watch for these Method A failure modes:<\/p>\n
\nMissing tenant filter<\/strong> \u2014 any findUnique({ where: { id } })<\/code> on tenant data is suspect. Prefer composite checks (id + tenantId<\/code>) or automated ORM scoping.<\/li>\nIDOR across tenants<\/strong> \u2014 authorization that checks \u201cuser is editor\u201d without also checking \u201cresource.tenantId === currentTenantId\u201d.<\/li>\nCache and file keys<\/strong> \u2014 Redis keys and storage paths should include tenant (or be reachable only through tenant-checked DB rows).<\/li>\nBackground jobs<\/strong> \u2014 enqueue tenantId<\/code> with the job payload; never infer it from ambient global state alone.<\/li>\nAmbiguous host resolution<\/strong> \u2014 if subdomains carry slugs but foreign keys store UUIDs, map slug \u2192 id explicitly before querying.<\/li>\nAnalytics shortcuts<\/strong> \u2014 admin \u201call tenants\u201d reports must be platform-only routes, never reused by tenant APIs.<\/li>\n<\/ul>\nHardening path as you mature:<\/p>\n
\nLint \/ code review checklists for tenant filters<\/li>\n Integration tests that attempt cross-tenant reads and expect 404<\/li>\n Optional Prisma (or ORM) middleware that auto-injects tenantId<\/code><\/li>\nOptional PostgreSQL RLS as defense-in-depth for the same discriminator column<\/li>\n<\/ol>\nAlkademy Press today relies on application-level filtering<\/strong> \u2014 clear, explicit, and sufficient for a disciplined codebase \u2014 with room to add automated scoping later without changing the underlying Method A model.<\/p>\nOne more practical tip: treat platform-admin \u201cview all tenants\u201d screens as a separate surface with separate authorization. Reusing a tenant list API without a platform role check is how internal tools accidentally become cross-tenant data dumps. In Press, platform concerns (provisioning, impersonation, global flags) sit above the tenant app, not beside it with weaker guards.<\/p>\n
Frequently Asked Questions<\/h2>\n What is multi-tenancy in SaaS?<\/strong>What are the main multi-tenancy implementation methods?<\/strong>tenant_id<\/code> column, (B) schema-per-tenant in one database, and (C) database-per-tenant. Hybrids and Postgres RLS build on these.<\/p>\nWhich multi-tenancy method does Alkademy Press use?<\/strong>tenantId<\/code> on domain tables. Tenant context is resolved from header, subdomain, custom domain, or JWT, and services filter every query by tenant.<\/p>\nIs shared-database multi-tenancy secure?<\/strong>When should I use database-per-tenant instead?<\/strong>How do you resolve which tenant a request belongs to?<\/strong>X-Tenant-Id<\/code>, subdomain, custom domain, and JWT tenant_id<\/code>. Alkademy Press checks them in that priority order, with the SPA typically sending the header for authenticated API calls.<\/p>\n