Class Ops

Overview

Class Ops is a comprehensive classroom management ecosystem designed to bridge the gap between administrative governance and daily academic execution. The platform's core technical challenge is modeling the complex relational web of academic entities—Departments contain Subjects, Subjects have Sections with capacity limits, Faculty are assigned to Subjects within Departments, Students enroll in Sections, and Classes track attendance and progress—all while keeping these interconnected records consistent in real-time.

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. Mobile-First React Native Interface

• ›Classroom-Optimized Design: Built the mobile 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.
• ›Dark-Mode Optimized: Implemented a dark-mode-first design system suitable for use in diverse classroom environments—dimly lit lecture halls, bright outdoor settings, and shared screen situations. Theme tokens support both dark and light modes with automatic switching based on system preferences.
• ›Offline Awareness: While not fully offline-capable, 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

• ›Express.js API Design: Built a RESTful API with layered middleware—authentication (JWT-based session validation), authorization (role-based permission checks), request validation (schema-based payload validation), and error handling (categorized error responses with appropriate HTTP status codes).
• ›PostgreSQL Schema Design: Designed a normalized schema 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.
• ›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.

Mobile-First Ecosystem

The React Native 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 from the home screen.
• ›Touch-Optimized Interactions: List items are sized for finger-tap accuracy, swipe gestures handle common actions (swipe to mark attendance, swipe to view details), and pull-to-refresh updates data without navigating away from the current view.
• ›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.

Redux State Management for Multi-Entity Data

The application manages complex interdependencies between academic entities. Redux provides a predictable state container 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.
• ›Optimistic Updates: When a user takes an action (assign faculty, update enrollment), the Redux store updates immediately while the API request is in flight. If the request fails, the store reverts to the previous state. This pattern makes the mobile app feel responsive even on slower connections.

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

• ›Digital Transformation: Successfully replaced manual spreadsheet-based tracking of subjects, faculty assignments, and enrollments with a centralized digital system, providing the institution with a single source of truth for academic operations.
• ›Real-Time Visibility: Administrators gained instant access to institutional health metrics—enrollment counts, faculty assignments, department staffing—without waiting for manually compiled reports.
• ›Mobile Accessibility: Delivered a mobile-first experience that educators actually use in classrooms and between classes, rather than a desktop-only tool that sits unused because it's inaccessible during active teaching hours.
• ›Data Integrity: PostgreSQL's relational constraints and transaction guarantees eliminated the data inconsistency issues inherent in spreadsheet-based tracking—enrollment counts are always accurate, faculty assignments never conflict silently, and department hierarchies remain structurally sound.
• ›Multi-Role Support: The role-based portal architecture serves administrators, teachers, and students from a single platform, with each role seeing exactly the information and capabilities relevant to their needs.

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 Redux 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 middleware 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.
• ›Redux may be heavier than needed for this application's state complexity. A simpler state management approach (React Context + useReducer, or Zustand) could reduce boilerplate while maintaining the normalized state pattern.

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 React Native for cross-platform mobile development, accepting the bridge performance overhead in exchange for a single codebase that serves both iOS and Android from a team with primarily web development expertise.
• ›Chose a mobile-first approach over a web-first approach, accepting the reduced screen real estate in exchange for meeting educators where they actually work—in classrooms and between classes, not at desks.