Class Ops

Class Ops

Overview

Class Ops is a classroom management platform for a multi-department institution: subjects, sections, faculty, and enrollments modeled as one consistent relational core. Role-based portals serve admins, teachers, and students from a single system, with enrollment capacity and schedule conflicts enforced at the data layer.

By digitizing course subjects, faculty assignments, and student tracking into one cohesive, mobile-first interface, Class Ops replaces fragmented spreadsheet-based tracking with a centralized system that provides real-time operational visibility. The mobile-first approach is deliberate: educators operate in classrooms, hallways, and faculty offices - not at desks - and their management tools need to work wherever they are.

Business Context: Digitizing Academic Governance

Traditional academic management relies on fragmented systems - faculty assignments tracked in spreadsheets, enrollment counts tallied manually, department reports compiled by hand from disconnected data sources. This fragmentation creates operational delays (information is always stale by the time it's compiled), data inconsistency (different spreadsheets show different numbers), and a lack of real-time insight for administrators making decisions about resource allocation.

The core problem: Academic institutions manage deeply interconnected data - a single faculty reassignment affects department headcounts, subject coverage, section availability, and student enrollment options. When this data lives in disconnected spreadsheets, changes don't propagate, and administrators make decisions based on incomplete or outdated information.

Stakeholder perspective:

• ›Administrators need a holistic view of institutional health - how many students are enrolled, which subjects have capacity, which departments are understaffed - without compiling data from multiple sources.
• ›Teachers need visibility into their assigned subjects, section rosters, and student information accessible from their phone between classes, not just from a desktop during office hours.
• ›Students need to see available sections, enrollment status, and class schedules in a consistent, up-to-date interface.

Constraints that shaped the architecture:

• ›Academic data is highly relational - the schema must enforce referential integrity (a section can't exist without a subject, a subject can't exist without a department) at the database level, not just the application level.
• ›The platform must work effectively on mobile devices in varied environments (classrooms with limited attention, hallways between classes, faculty offices with desks).
• ›Role-based access is non-negotiable - teachers should not see administrative configuration, and students should not modify enrollment records directly.
• ›The system replaces manual processes, so data migration and initial adoption must be frictionless for non-technical faculty.

What I Built

1. Enterprise Education Dashboard

• ›Institutional Health Overview: Built a "Quick Snapshot" dashboard providing real-time aggregate metrics - Total Users, Teachers, Admins, Subjects, Departments, Classes, and Enrollments. Each metric is a live query, not a cached count, ensuring administrators always see current state.
• ›Interactive Visualizations: Implemented donut charts visualizing user distribution by role (Teacher, Admin, Student) and enrollment distribution by department. Chart interactions link to detailed drill-down views - clicking the "Engineering" segment of the department chart navigates to that department's subject and faculty breakdown.
• ›Activity Streams: Built real-time activity feeds showing recent institutional changes - new class additions, faculty assignments, enrollment updates - giving administrators immediate awareness of operational changes without waiting for reports.

2. Subject & Course Management

• ›Subject-First Workflow: Engineered a subject-centric management interface where instructors and admins can create subjects, define sections with capacity limits (e.g., "35 spots available"), assign faculty, and toggle active/inactive status. The workflow is designed around the academic planning cycle - set up subjects for the upcoming term, configure sections, assign faculty, then open enrollment.
• ›Capacity & Enrollment Tracking: Each section tracks current enrollment against maximum capacity, with visual indicators (green/yellow/red) showing availability status. When a section reaches capacity, enrollment is automatically restricted, and waitlist functionality notifies administrators of demand exceeding supply.
• ›Department Hierarchy Navigation: Built a hierarchical navigation structure - Institution → Department → Subject → Section - that mirrors the organizational structure of academic institutions. Each level shows aggregate metrics rolled up from its children (e.g., a department shows total enrolled students across all its subjects).

3. Faculty & Role-Based Portals

• ›Faculty Profile Management: Built detailed faculty profile views including contact information, department affiliation, assigned subjects, teaching schedule, and workload metrics. Administrators can assign and reassign faculty across subjects with the system enforcing schedule conflict detection.
• ›Role-Specific Navigation: Each portal (Admin, Teacher, Student) has a distinct sidebar navigation optimized for its role's primary tasks. Admins see Home, Subjects, Departments, Faculty, Enrollments, and Classes. Teachers see their assigned subjects, section rosters, and class schedules. Students see available courses, their enrollments, and class information.
• ›Permission Boundaries: Implemented middleware-level authorization that enforces role boundaries at the API level - not just the UI. Even if a teacher's client somehow constructs an admin API request, the backend rejects it based on the authenticated user's role. This defense-in-depth approach prevents permission bypass.

4. Responsive Next.js Web Interface

• ›Classroom-Ready Design: Built the web interface with the understanding that educators use it in short bursts - checking a roster between classes, marking attendance during a session, reviewing a student's enrollment during a meeting. The UI prioritizes quick access to frequent actions over comprehensive feature depth, with mobile-first layouts that adapt from phones to desktop dashboards.
• ›Dark-Mode Support: Implemented a design system with dark mode and light mode suitable for diverse classroom environments - dimly lit lecture halls, bright outdoor settings, and shared screen situations. Theme tokens support both modes with automatic switching based on system preferences.
• ›Resilient Data Handling: The app implements optimistic UI patterns and graceful degradation - actions that fail due to connectivity issues are queued with user-visible retry indicators, preventing data loss when educators move through areas with poor connectivity.

5. Backend & Data Architecture

• ›NestJS API Design: Built a RESTful API on NestJS with dependency injection, middleware pipelines for authentication and request validation, role-based guards (Admin/Teacher/Student), and standardized error handling - structured to support multi-tenant expansion without architectural refactoring.
• ›Drizzle ORM on Neon Postgres: Defined the normalized schema in TypeScript with Drizzle ORM against Neon serverless Postgres, with foreign key constraints enforcing the academic entity hierarchy. Cascading updates and deletes are carefully configured - deleting a department cascades through its subjects and sections, while faculty assignments use soft-delete to preserve historical records. Enrollment capacity and conflict-sensitive writes run inside Drizzle transactions.
• ›Query Optimization: Identified and optimized the most frequent query patterns - dashboard aggregate queries use indexed COUNT operations, listing views use paginated queries with OFFSET/LIMIT, and hierarchical navigation uses JOIN queries optimized with composite indexes on (department_id, subject_id) and (subject_id, section_id).

Architecture Highlights

Relational Data Modeling for Education

The PostgreSQL schema is the backbone of the system's integrity. Academic data has deep relational dependencies:

• ›A Department has many Subjects. Deleting a department must cascade through all its subjects and their sections.
• ›A Subject belongs to a Department and has many Sections. Each Subject can have multiple Faculty assigned.
• ›A Section belongs to a Subject and has a capacity limit. Students enroll in Sections, not Subjects directly.
• ›A Faculty member belongs to a Department and can be assigned to multiple Subjects. Schedule conflicts must be detected at assignment time.
• ›An Enrollment links a Student to a Section with status tracking (active, dropped, waitlisted).

These relationships are enforced at the database level with foreign keys, check constraints, and triggers - not just at the application level. This means the system cannot enter an inconsistent state even if the API has a bug, because PostgreSQL will reject the invalid operation.

Responsive Web Experience

The Next.js application is designed for the operational rhythm of educators:

• ›Quick Access Patterns: The most common actions (check roster, view schedule, see enrollment counts) are accessible within two taps or clicks from the home screen.
• ›Responsive Interactions: Layouts adapt from phone (student and teacher access between classes) to desktop (admin dashboards), with touch-friendly targets on small screens and dense information views where space allows.
• ›Contextual Navigation: The sidebar adapts based on the authenticated user's role, showing only the navigation items relevant to their permissions. Teachers don't see administrative configuration options; students don't see faculty management.

Zustand State Management for Multi-Entity Data

The application manages complex interdependencies between academic entities. Zustand provides a lightweight client store where:

• ›Normalized Entity Storage: Departments, Subjects, Sections, Faculty, and Students are stored in normalized slices keyed by ID. This prevents data duplication - a faculty member appears once in the store regardless of how many subjects they're assigned to.
• ›Derived State via Selectors: Computed values (enrollment count per section, faculty load per department, total students per subject) are derived through memoized selectors rather than stored directly. This ensures derived values are always consistent with the underlying entity data.
• ›React Server Components First: Pages that don't need interactivity render as React Server Components with zero client JavaScript by default; Zustand covers the interactive client state (filters, selection, form drafts). This keeps pages fast while preserving rich interaction where it matters.

Technical Deep Dive: Multi-Entity Relational Data Modeling for Education

The most architecturally significant challenge in Class Ops was designing a data model that accurately represents the complex, hierarchical relationships in academic institutions while supporting the query patterns the application needs.

The Problem: Academic data isn't a simple parent-child hierarchy. It's a web of many-to-many relationships with constraints. A faculty member belongs to a department but can teach subjects in other departments. A student enrolls in sections of subjects across multiple departments. Sections have capacity limits that must be enforced atomically (two students can't take the last spot simultaneously). Schedule conflicts must be detected across a faculty member's full assignment set, not just within a single subject.

The Schema Design Approach:

1. ›

   Entity Identification: Mapped the core entities (Department, Subject, Section, Faculty, Student, Enrollment, Class) and their relationships. Each entity has a clear primary key and lifecycle (created, active, archived/soft-deleted).

2. ›

   Relationship Mapping:

   • ›Department → Subject: One-to-many with cascade delete (removing a department removes its subjects).
   • ›Subject → Section: One-to-many with cascade delete.
   • ›Faculty → Subject: Many-to-many through an assignment junction table that includes assignment metadata (start date, end date, primary/secondary designation).
   • ›Student → Section: Many-to-many through the Enrollment table that includes enrollment status and timestamps.
   • ›Section → Class: One-to-many (a section has many class sessions/meetings).
3. ›

   Constraint Enforcement:

   • ›Section capacity is enforced with a CHECK constraint and a pre-enrollment trigger that counts current active enrollments against the capacity limit.
   • ›Faculty schedule conflicts are detected at the application level (not database level, since they require time-range overlap calculations) before the assignment is committed.
   • ›Referential integrity via foreign keys ensures that no orphan records can exist - every enrollment references a valid student and section, every section references a valid subject.
4. ›

   Index Strategy: Composite indexes are designed for the application's actual query patterns:

   • ›(department_id, status) for listing active subjects within a department.
   • ›(section_id, enrollment_status) for counting active enrollments in a section.
   • ›(faculty_id, assignment_status) for listing a teacher's current assignments.
   • ›(student_id, enrollment_status) for listing a student's active enrollments.
5. ›

   Soft Delete for Historical Integrity: Faculty assignments and enrollments use soft-delete (a deleted_at timestamp) rather than hard delete. This preserves historical records for reporting (which faculty taught which subject in which term) while keeping active queries clean through a WHERE deleted_at IS NULL convention.

Why this matters: The data model is the foundation that everything else builds on. If the schema doesn't enforce academic entity relationships correctly, the application must compensate with complex validation logic that's fragile and error-prone. By investing in a rigorous relational design upfront, the API layer becomes simpler - it can trust that the database won't allow inconsistent state.

Key Challenges & Solutions

• ›

  Challenge: Academic entities have deep relational dependencies - deleting a department affects all its subjects, sections, enrollments, and faculty assignments. Cascading these changes safely is complex. Approach: Used PostgreSQL foreign key constraints with carefully configured cascade rules. Department deletion cascades through subjects and sections. Faculty assignments and enrollments use soft-delete to preserve historical records while removing them from active views. Why: Handling cascading deletes in application code is error-prone - if the API server crashes mid-cascade, the data is left in an inconsistent state. Database-level cascades are atomic and guaranteed to complete fully or not at all.

• ›

  Challenge: Two students enrolling in a section with one remaining spot simultaneously could both succeed, exceeding capacity. Approach: Implemented enrollment capacity checks within a PostgreSQL transaction with a row-level lock on the section record. The transaction reads the current enrollment count, checks against capacity, and inserts the enrollment atomically. Concurrent requests are serialized by the lock. Why: Application-level capacity checks (check count, then insert) have a race condition window between the check and the insert. Database-level locking eliminates this race condition entirely.

• ›

  Challenge: Faculty schedule conflict detection requires comparing time ranges across all of a teacher's subject assignments, which is computationally complex and doesn't map cleanly to simple SQL constraints. Approach: Implemented schedule conflict detection at the application level using time-range overlap algorithms before committing faculty assignments. The API validates that the new assignment's time slots don't overlap with any existing assignments for the same faculty member. Why: Time-range overlap detection involves comparing start/end times across multiple records, which is more naturally expressed as application logic than database constraints. The trade-off is that the constraint isn't enforced if someone bypasses the API, but since all writes go through the API, this is acceptable.

• ›

  Challenge: The institutional dashboard needs aggregate metrics (total students, enrollment counts per department, faculty load distribution) that would be expensive to compute on every page load with COUNT queries across large tables. Approach: Used PostgreSQL indexed COUNT operations with pre-computed covering indexes for the most frequent aggregate queries. For computationally expensive aggregations (enrollment trends over time), implemented background calculation with cached results that refresh on a schedule. Why: Real-time aggregate queries are acceptable for small-to-medium institutions where the data volume keeps COUNT operations fast. The indexed approach avoids the complexity of materialized views while maintaining acceptable query times.

Outcomes

• ›Single source of truth: One relational model replaced scattered spreadsheets; enrollments, faculty assignments, and department data stay consistent.
• ›Real-time visibility: Admins see live institutional health metrics without waiting for manually compiled reports.
• ›Multi-role support: Each role sees exactly its information and capabilities; the API enforces the boundaries, not just the UI.
• ›Data integrity: Database-level constraints and transactions close the consistency gaps spreadsheets cannot.

Engineering Takeaways

Class Ops demonstrated the technical complexity of building multi-role, multi-entity platforms for the education sector. The key insight is that in domain-heavy applications like academic management, the data model is the architecture - get the schema right and the application layer becomes straightforward; get it wrong and you're fighting data inconsistency bugs forever.

Patterns I'd reuse:

• ›Database-level enforcement of relational integrity (foreign keys, cascades, check constraints) rather than trusting application code to maintain consistency. The cost of designing rigorous constraints upfront is far less than debugging data corruption later.
• ›Normalized Zustand state with memoized selectors for derived data. In multi-entity applications, this pattern prevents the data duplication bugs that plague denormalized state designs.
• ›Role-based authorization enforced at the guard level (defense-in-depth) rather than only at the UI level. This ensures security even if the client-side code has bugs.

What I'd reconsider:

• ›The current REST API design uses separate endpoints for each entity's CRUD operations, which can lead to chatty request patterns when the dashboard needs data from multiple entities. A GraphQL layer (or at least aggregated REST endpoints) would reduce the number of round trips for data-heavy views.
• ›Zustand's simplicity serves the current app size well, but as the feature set grows, the thinner dev-tools story compared to Redux DevTools could make complex state flows harder to debug. A migration path to Redux Toolkit stays open if that threshold is reached.

Trade-offs acknowledged:

• ›Chose PostgreSQL over MongoDB for the strong relational integrity guarantees, accepting the schema rigidity (migrations required for structural changes) in exchange for database-enforced data consistency.
• ›Chose a responsive Next.js web app over a native mobile client, accepting a single web codebase in exchange for reaching every device educators already carry, from phones to desktops.
• ›Chose a mobile-first responsive approach, accepting tighter layout constraints on small screens in exchange for meeting educators where they actually work - in classrooms and between classes, not at desks.