MUN-C SMS
Multi-Tenant School Management SaaS
One backend, many schools — isolated configuration per institution with 15+ modules across 5 user tiers.
Overview
The story behind it
MUN-C SMS is a multi-tenant school management platform I architected end-to-end on the backend. Every institution onboarded onto the platform gets its own isolated configuration space — roles, modules, fee structures, and billing plans are independently switchable without touching another tenant's data or code path.
The challenge was to make multi-tenancy feel invisible: a single deployment serving every school, yet with the isolation guarantees of separate installations. That shaped every layer — tenant-aware MongoDB document design, per-request tenant resolution middleware, Redis key namespacing, and RBAC policies that compose tenant scope with user tier permissions.
The platform ships 15+ core modules covering the full academic operations surface: admissions, academic scheduling, attendance, examinations, fee processing, payroll, transport, library, inventory, and granular access control — consumed by web dashboards and mobile clients across 5 distinct user tiers.
MUN-C SMS is built at Kasper Infotech and is currently in pre-production testing with pilot institutions, hardening tenant onboarding, billing flows, and module configuration ahead of the public rollout.
What it does
Key features
- Multi-tenant isolation — per-institution configuration of roles, modules, and billing with zero cross-tenant leakage
- 15+ core modules — admissions, scheduling, attendance, exams, fees, payroll, transport, library, and more
- 5 user tiers — Admin, Teacher, Student, Parent, and Staff, each with scoped RBAC policies
- Real-time layer — Socket.IO messaging and notifications backed by Redis Pub/Sub for horizontal scaling
- Push infrastructure — FCM topic and device-group notifications for fee reminders, circulars, and alerts
- Billing engine — flexible fee structures, discounts, installment plans, and reconciliation reports
How it's built
Architecture & implementation
- Tenant resolution middleware reads the request origin and injects tenant scope into every query and cache key
- Mongoose document schemas carry a tenant discriminator with compound indexes prefixed by tenant for isolation-safe reads
- Redis keys are namespaced per tenant (tenant:<id>:<entity>) with TTL policies tuned per data class
- Socket.IO rooms are tenant-scoped channels; Redis Pub/Sub fans events out across horizontally scaled nodes
- JWT access tokens embed tenant + tier claims, so authorization decisions stay stateless at the edge
- PM2 cluster mode behind Nginx with zero-downtime reloads; GitHub Actions runs lint, tests, and deployment gates
Highlights
Engineering highlights
- Multi-tenant architecture with isolated schema logic for independent institution configuration
- Real-time fleet GPS tracking and instant messaging over Socket.IO, backed by Redis Pub/Sub for horizontal scaling
- 15+ core modules serving 5 user tiers: Admin, Teacher, Student, Parent, Staff
Takeaways
Lessons learned
- Designing tenant scoping into the data layer first is far cheaper than retrofitting it into queries later
- Compound indexes that lead with the tenant key keep every tenant's hot path fast as the dataset grows
- A config engine beats hard-coded feature flags when every tenant wants a different workflow