Routine Management System
Automated academic timetable generation that resolves teacher, room and batch constraints and makes remaining conflicts explicit instead of hiding them.
- Stack
- 5 technologies
The problem
What needed solving
Manual timetable construction is slow, and its failures are silent — conflicts introduced by a single reassignment typically surface only once the schedule is already in use.
My role
Responsibilities
Domain modelling and full-stack implementation: constraint model, schedule generation and conflict reporting, persistence design, and the multi-perspective front end.
The solution
Architecture summary
An explicit constraint model over teachers, rooms, batches and time slots, with a generation pass that reports unresolvable conflicts by name, backed by PostgreSQL uniqueness guarantees and cached published views.
Case study
In detail
Context
Timetabling is a constraint satisfaction problem that most institutions solve by hand, in spreadsheets, under time pressure. The manual process is slow and the results are fragile: a single teacher reassignment can invalidate the schedule in ways nobody notices until the week it takes effect.
Approach
The system models the real constraints explicitly — teacher availability, room capacity and type, batch load, course-hour requirements, and institutional rules about consecutive sessions — then generates candidate schedules against them.
The important design choice was how to handle the cases the solver cannot satisfy. Rather than silently producing a partial schedule, unresolved constraints are surfaced as named conflicts with the specific entities involved, so a coordinator can make an informed trade-off instead of discovering the clash later.
Architecture
- Constraint model expressed as first-class domain entities rather than embedded conditionals
- Generation pass that scores and reports candidate schedules with their violated constraints
- PostgreSQL storage of published routines with uniqueness enforced per teacher, room and time slot
- Redis caching of published routine views, invalidated on every republication
- Angular interface with per-teacher, per-room and per-batch views over the same underlying schedule
Outcomes
What changed
- Timetable construction reduced from a manual spreadsheet exercise to a reviewable generated draft
- Unsatisfiable constraints reported explicitly instead of producing a silently partial schedule
- Teacher, room and time-slot collisions prevented by database uniqueness rather than review
- One schedule presented through per-teacher, per-room and per-batch views without duplicating data