Multi-Tenancy

Our platform is built on a sophisticated multi-tenant architecture that allows us to serve multiple customers (tenants) from a single instance of the application while ensuring data is securely isolated.

Key Concepts

Organization-Scoped Routing

All tenant-specific routes are scoped using a dynamic [orgSlug] parameter in the URL. For example, a user accessing the dashboard for "Acme Corp" would use a URL like /acme-corp/dashboard. This approach provides a clean, user-friendly URL structure while maintaining clear separation between tenants.

Role-Based Access Control (RBAC)

We employ a robust RBAC system to manage permissions within and across tenants. Our user hierarchy includes:

• Super Admins: Have platform-wide access and can manage all organizations.
• Resellers: Can manage the client organizations assigned to them.
• Organization Members: Have access only to their own organization's data, with roles like admin or member that grant different levels of permissions within that organization.

Data Isolation

The cornerstone of our multi-tenant architecture is strict data isolation. This is enforced at multiple levels:

• Database: We use Prisma schema design patterns to ensure that all database queries are scoped to the user's current organization. This prevents any possibility of one tenant accessing another's data.
• API and Server Actions: All backend operations include access validation checks to verify that the user has the necessary permissions for the requested organization.
• Middleware: Our Next.js middleware intercepts incoming requests to validate the user's access to the organization specified in the URL slug.

Implementation Patterns

Middleware for Access Validation

Our middleware.ts file is responsible for protecting routes and ensuring that users can only access organizations they belong to. It validates the orgSlug from the URL against the user's Clerk authentication session.

Super Admin Organization Switching

Super admins have the ability to switch between different client organizations to provide support or manage data. This is handled through a secure context-switching mechanism that preserves the super admin's session while allowing them to view the application as if they were a member of the client's organization. This context is managed via cookies and validated on every request.

Secure Data Fetching

All data-fetching operations, whether in Server Components or API routes, must follow our established patterns for secure, organization-scoped data access. This typically involves using helper functions that automatically apply the necessary database filters based on the user's authenticated organization.