CloudCampus system design
How I Designed Multi-Tenancy for CloudCampus
Problem
CloudCampus is a School ERP SaaS platform, so the core architecture question is not only "how do users log in?" It is "which tenant, school, role, and workflow is this user allowed to touch?"
A school platform also has many user types: Super Admin, Tenant Admin, School Admin, Teacher, Finance Staff, Staff, Parent, and Student. The backend needs to support those roles without letting one school or tenant see another school's data.
Design
The design starts with a tenant and school hierarchy. A tenant can represent a trust, school group, or independent school. A school belongs to a tenant. Users receive access through server-owned role and school context instead of client-supplied identifiers.
The backend uses Java and Spring Boot with modular domains. Identity and access control sit close to authentication because every module depends on them. Academic setup, attendance, homework, exams, fees, notices, documents, reporting, and AI-ready foundations receive a validated user context before doing business work.
Tradeoffs
Schema-per-tenant isolation can provide stronger data separation, but it increases migration and operations complexity. A shared-schema model is easier to operate during active product development, but it requires disciplined query guards, service-level checks, and regression tests.
For CloudCampus, the current design keeps tenant and school scoping visible and testable while the product moves toward pilot readiness. Production hardening still needs stable HTTPS staging, SMTP proof, hosted backup/restore proof, monitoring, and more operations evidence.
Implementation Notes
- Keep tenant and school boundaries explicit in the data model and service layer.
- Resolve access context on the server from authenticated user grants.
- Make new ERP modules easier to add without rewriting identity and access rules.
- Preserve auditability for onboarding, invitations, role changes, and school-scoped mutations.
The frontend can ask for a workflow. The backend decides whether the authenticated user can access that tenant, school, object, and role-specific action.
Lessons Learned
- Tenant context should be a backend-owned decision, not a loose request parameter.
- Role checks become safer when combined with tenant, school, and object ownership checks.
- Hosted backup/restore and monitoring proof should be completed before real pilot usage.