TrainIQ: Multi-Tenant LMS Isolation with Local AI
How TrainIQ ships a Flask multi-tenant corporate LMS with three-layer data isolation, Stripe billing, a CEO platform console, and an Ollama-local AI suite — LearnIQ, AnalyticsIQ, ProctorIQ, and CreatorIQ — without cloud LLM keys.
SaaS LMS is an isolation problem
A corporate learning platform fails the moment Tenant A can see Tenant B's exams, uploads, or score histories. TrainIQ is designed around that failure mode: every customer organisation is a tenant with its own office key, plan limits, and hard data boundaries.
AI features are deliberately local via Ollama. Training content and learner performance should not have to leave the deployment perimeter to get tutoring or proctoring narratives.
Three layers of tenant isolation
PostgreSQL rows carry tenant_id on every core table. MongoDB GridFS uses a dedicated database per tenant (trainiq_t_<id>) so file blobs inherit isolation by construction. Redis enforces rate and plan limits that cannot be bypassed from the app tier alone.
That layering matters because LMS workloads mix relational records with large binary uploads. One store cannot honestly cover both without either leaking files or overloading relational tables.
Isolation map
| Layer | Mechanism | Protects |
|---|---|---|
| PostgreSQL | tenant_id on core tables | Courses, exams, scores, billing |
| MongoDB GridFS | Per-tenant database | Uploads and study materials |
| Redis | Plan / rate limit keys | Abuse and cross-tenant quota bleed |
| Auth scope | Office Key + roles / SSO | Login boundary per organisation |
Three processes, three audiences
Learners and tenant admins hit the web worker. Platform staff use a separate platform worker for cross-tenant ops, revenue, and support enter. Background schedulers and agent actions run on an ops-worker that consumes a Redis event bus when enabled.
Splitting processes keeps a CEO console failure mode from taking down exams, and keeps long-running agent actions off the request path learners feel.
Schematic responsibility split across processes
Invented load sketch: keep learner UX on web, CEO tooling on platform, and asynchronous agent work on ops-worker.
Source — Illustrative schematic — not production metrics
Local AI suite without API keys
LearnIQ summarises and chats against GridFS document text. AnalyticsIQ diagnoses weaknesses from score history. ProctorIQ produces trust scoring narratives. CreatorIQ drafts course outlines. Exam AI helps admins generate questions from topic prompts.
Running these on Ollama (Gemma) is a product decision: enterprises evaluating an LMS often block outbound LLM traffic long before they block Docker. Local inference keeps the demo and the deployment story aligned.
If your SaaS AI feature requires every customer to provision an OpenAI key on day one, you have narrowed the buyer set before the first course is uploaded.
Billing and observability as product surfaces
Stripe powers trial-to-enterprise plan progression with checkout, webhooks, and a customer portal. Prometheus, Grafana, and Alertmanager cover the operational side that multi-tenant SaaS actually dies on — silent queue backups and database saturation.
TrainIQ's lesson is compositional: isolation + process split + local AI + billing + observability. Any one demo feature is easy; the combination is what makes it a platform.