OSEDUI: Multi-Tenant SaaS Architecture
The Architectural Friction (The Problem)
EdTech platforms serving multiple institutions face a critical scaling challenge: ensuring absolute data isolation between schools while sharing core infrastructure to keep operational costs sane. A single misrouted API query in a legacy monolith can expose sensitive student records across different school districts.
The iHexe Execution (The Solution)
This demonstration utilizes a schema-per-tenant PostgreSQL architecture paired with Next.js middleware. It enforces strict role-based access for admins, teachers, students, and parents. Even though all schools operate on the same core database, their data lives in completely separate, encrypted schemas, physically isolating each tenant's records.
Extracted Slug: "apex"
x-tenant-schema: schema_tenant_apex
Scope: Apex Technical
The iHexe Multi-Tenant Protocol
Next.js Edge Routing & Subdomain Middleware
We eliminated manual tenant switching. We deployed custom Next.js middleware at the edge to instantly parse incoming requests (e.g., apex.demo.osedui.internal). The edge server securely identifies the tenant ID in milliseconds and routes the user to their mathematically isolated environment before the DOM even begins to render.
PostgreSQL Schema-Level Isolation
Shared databases are a liability. We engineered a strict Schema-per-Tenant architecture in PostgreSQL. Even though all schools operate on the same core codebase, their data lives in completely separate, encrypted database schemas. A breach in one tenant cannot physically cascade to another.
n8n Global Orchestration Pipelines
Multi-tenant systems require global synchronization. We deployed robust n8n webhook pipelines to handle the heavy background processing. When a global curriculum update is pushed, or recurring tuition is billed, our n8n nodes autonomously orchestrate the logic across all 150+ tenant schemas simultaneously without blocking the main Node.js event loop.
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { getTenantBySubdomain } from '@/lib/tenant-resolver';
export async function middleware(request: NextRequest) {
const hostname = request.headers.get('host') || '';
const url = request.nextUrl.clone();
// Extract subdomain (e.g. "boston" from "boston.osedui.com")
const subdomain = hostname.split('.')[0];
const isCustomDomain = !hostname.includes('osedui.com');
if (!subdomain || subdomain === 'www' || subdomain === 'app') {
return NextResponse.next();
}
// 1. Instant L1 Redis Lookup for Tenant Mapping (< 1.8ms)
const tenant = await getTenantBySubdomain(subdomain, isCustomDomain);
if (!tenant) {
url.pathname = '/404-tenant-not-found';
return NextResponse.rewrite(url);
} // 2. Inject Mathematically Isolated Headers before DOM Render
const requestHeaders = new Headers(request.headers);
requestHeaders.set('x-tenant-id', tenant.id);
requestHeaders.set('x-tenant-schema', tenant.schemaName);
requestHeaders.set('x-tenant-role-matrix', tenant.roleMatrixHash); // 3. Rewrite request internally to isolated tenant layout
return NextResponse.next({
request: {
headers: requestHeaders,
},
});
}Building a multi-tenant platform? Let's talk about your isolation and scaling needs.
Enforce strict schema-level data isolation, deploy Next.js edge subdomain middleware, and scale to hundreds of tenant environments.