Sankhya — Business Operations Platform
A multi-tenant CRM replacing spreadsheets for an education business with 300+ API routes and 85+ database models.
Sankhya is a ground-up business operations platform built for an education company that had outgrown spreadsheets. The platform covers every aspect of the business: student enrolment and lifecycle, batch and attendance management, lecture delivery with live streaming, fee collection and payment splitting across multiple teachers, WhatsApp campaign management, automated Exotel calling for session reminders and birthday wishes, internal e-commerce, and a full financial reporting suite. It is built as a multi-tenant system supporting multiple organizations under one deployment. Currently in staging with 300+ REST API routes and 85+ PostgreSQL models.
The business was running on a collection of disconnected spreadsheets — student records in one place, attendance in another, fees tracked manually, lecture schedules managed by hand, and campaigns sent individually. As the student base grew, critical information was falling through the gaps: missed follow-ups, incorrect fee calculations, no visibility into which students were attending which lectures, and no way to run campaigns at scale. The business needed one system that connected every operation end to end.
Designed and built the entire platform as a solo full stack engineer over several months — architecture, database schema, backend API, frontend, third-party integrations, and deployment pipeline. Every module from the student CRM to the RTMP streaming bridge was designed and implemented by me.
Engineering challenges
Multi-Tenant Data Isolation
Multiple organizations sharing one deployment meant student data, financial records, and campaign history had to be completely isolated between tenants — a leak would be a serious trust failure.
Implemented logical tenant isolation with tenant_id on every model and repository-level query scoping that automatically appends the tenant filter. RBAC middleware verifies tenant context on every API route before any database operation executes. Frontend role checks are purely UX — all security lives on the backend.
Browser-to-RTMP Live Streaming Bridge
Teachers needed to stream live lectures directly from the browser to YouTube Live without installing OBS or any native streaming software — browsers can't output RTMP natively.
Built a custom WebSocket-to-RTMP media bridge on Node.js. The browser captures the camera feed using MediaRecorder API and streams binary chunks over a WebSocket connection to the server. The server receives these chunks and pipes them into a spawned FFmpeg process via stdin, which transcodes the stream to H.264/AAC in an FLV container and forwards it to the YouTube RTMP ingest endpoint in real time.
Teacher Payment Split Engine
Fee distribution between multiple teachers was complex — some teachers were on a fixed salary model, others on a per-enrolled-student percentage model (e.g. 5% per student). Manual calculation was error-prone and took hours at month end.
Built a payment split engine that models each teacher's contract — salary-based or percentage-based — and calculates earnings from the student enrolment and attendance data already in the system. Split calculations are logged as immutable ledger entries so every payout is fully auditable.
Concurrent Attendance Under Race Conditions
Multiple facilitators marking attendance for the same batch at the same time caused duplicate entries and inconsistent counts — a classic read-modify-write race condition.
Wrapped attendance marking in a database transaction using SELECT FOR UPDATE to pessimistically lock the batch attendance record during the operation. This ensures only one write completes per batch per tick without requiring Serializable isolation across the entire system.
WhatsApp Campaign Engine at Scale
Sending personalized WhatsApp messages to hundreds of students involved complex template management, delivery tracking, and API rate limit handling — doing this synchronously in a request thread would timeout.
Built an async campaign engine: campaign jobs are validated and queued immediately, returning a 202 to the user. Background workers process the queue, handle Meta API rate limits with exponential backoff, track delivery status per recipient, and update the campaign dashboard in real time.
Exotel Automated Calling Integration
Session reminders and birthday call workflows needed to trigger automatically based on schedule data in the CRM, without manual intervention.
Built scheduled cron jobs that run against student and session data to identify who needs a call that day. Calls are dispatched via Exotel's API with personalized message templates. A distributed Redis lock prevents duplicate calls from running when the system scales horizontally.
Architecture
What we built
Student Lifecycle Management
Complete student journey from lead to enrolment to graduation — profile management, batch assignment, progress tracking, and document storage in one place.
Batch and Attendance System
Daily and per-lecture attendance tracking with facilitator assignment, attendance analytics, and automated alerts for consistent absences.
Live Lecture Streaming
Teachers stream directly from the browser to YouTube Live without any additional software. A custom WebSocket-to-RTMP bridge handles the protocol translation in real time.
Fee Collection and Payment Splits
Fee management with support for multiple payment schedules. Teacher earnings calculated automatically — salary-based or per-enrolled-student percentage — with full audit trail.
WhatsApp Campaign Engine
Targeted campaigns to student segments with template management, scheduled delivery, per-recipient tracking, and Meta API rate limit handling via async processing.
Exotel Automated Calling
Session reminder and birthday wish calls dispatched automatically from CRM schedule data. Call logs and delivery status tracked per student.
Role-Based Access Control
Granular permission system — admins, facilitators, coordinators, and finance roles each see and can act on exactly what their role requires. All permissions enforced at API level.
Internal E-Commerce Module
Product catalog and order management for course materials and related products, integrated with student accounts and the fee system.
Financial Reporting Suite
Revenue dashboards, fee collection reports, teacher payout summaries, and payment split reconciliation — built from ledger data, not spreadsheet exports.
Appointment and Scheduling
Session scheduling with Zoom integration, calendar management, and automated reminders through WhatsApp and automated calls.
Technical highlights
Custom WebSocket-to-RTMP streaming bridge — browser MediaRecorder → Node.js WebSocket → FFmpeg stdin → YouTube RTMP ingest
Multi-tenant RBAC with repository-level query scoping — tenant_id filter applied automatically on every database operation
Async WhatsApp campaign engine with Celery workers, exponential backoff on Meta API rate limits, and per-recipient delivery tracking
Pessimistic row locking (SELECT FOR UPDATE) on attendance operations to prevent concurrent write race conditions
Immutable payment split ledger — teacher earnings calculated from enrolment and attendance data, logged as append-only entries
Redis distributed locking on scheduled call jobs to prevent duplicate dispatch across horizontal scaling
JWT with httpOnly cookies, short-lived access tokens, and refresh token rotation for session security
300+ REST API routes organized across 15+ domain modules with consistent versioning and error handling
85+ PostgreSQL models with carefully designed foreign key relationships and index strategy
Add screenshots here — product gallery, admin panel, or key screens.
The impact
300+
REST API routes
85+
Database models
15+
Business modules
Multi-tenant
Architecture with RBAC
Real-time
Browser-to-RTMP streaming
Async
Campaign and calling engine
Business outcomes
Single Source of Truth
Every aspect of the business — students, attendance, fees, lectures, campaigns — lives in one connected system instead of disconnected spreadsheets.
Automated Revenue Operations
Teacher payment calculations that took hours of manual work are now computed automatically from attendance and enrolment data with a full audit trail.
Scalable Communication
WhatsApp campaigns and automated calls that previously required manual effort per student now run at scale from the dashboard.
Lessons learned
Building a streaming bridge from browser to RTMP is significantly more complex than it looks — backpressure management between WebSocket input and FFmpeg stdin required careful buffer monitoring to prevent memory accumulation
Multi-tenant architecture decisions made early in the schema design are very expensive to change later — getting the tenant isolation model right before building features saved significant rework
Async campaign processing is the only viable approach for bulk messaging — synchronous delivery caused timeout failures above 50 recipients
Immutable ledger design for payment splits is worth the extra upfront modeling — it makes month-end reconciliation trivial and disputes easy to resolve