Problem
CloudCampus is a School ERP SaaS platform, so the core architecture question is not only how users log in. It is which tenant, school, role, and workflow an authenticated user is 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 goals
- Keep tenant and school boundaries explicit.
- Derive access context on the server.
- Support multiple roles without duplicating security rules.
- Make future modules easier to add.
- Preserve traceability for sensitive flows.
Backend shape
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, and reporting should receive a validated user context before performing business work.
The key design decision is to avoid treating tenancy as a loose request parameter. Tenant and school context must be resolved from authenticated user claims, stored access grants, and server-side checks.
Tradeoffs
Schema-per-tenant isolation can provide stronger data separation, but it increases migration and operational complexity. Shared-schema tenant scoping is easier to operate but requires disciplined query guards and tests. CloudCampus is still under active development, so the design keeps tenant isolation visible and reviewable while the product moves toward pilot readiness.
Next improvements
- Add stronger integration tests around tenant boundary violations.
- Add migration and backup proof for production operations.
- Add monitoring around cross-tenant access failures.
- Document module-level authorization rules for each role.