During a college fest, On-Duty Amrita granted on-duty attendance for over 5,000 students in under 10 days. I built the application to support that university workflow.
The central problem was specific: attending an event does not identify which classes a student should receive attendance for. Each grant needed checks against that student's timetable and active slots.
That requirement shaped the system more than the number of people using it. A successful grant had to correspond to the right student and the relevant timetable slots.
The domain rule behind an attendance grant
On-duty attendance records an approved activity in place of normal class attendance. During a fest, a student's event participation and academic schedule must therefore meet in the same workflow.
A simple event check-in answers whether a person participated. An on-duty grant also needs to identify the applicable class slots. Different students can have different timetables, so the event alone cannot determine the result.
At the domain level, the workflow was:
Student → timetable lookup → active-slot checks → on-duty attendance grantThe timetable and slot checks were part of each grant. They explain why a single attendance action involved more work than a single database write.
Implementation scope
The application used React for the interface, Node.js and Express for the backend, and MongoDB for storage. The project also used Docker and Docker Compose for deployment configuration.
My contribution was the on-duty attendance application: taking the university workflow into software and making it usable during the event. The source remains proprietary, so this account describes the workflow and outcome without exposing student records or private implementation details.
The key design boundary is between a request from the interface and a valid attendance grant. A submitted action expresses what someone wants to do. The timetable determines which slots that action can apply to.
Keeping that distinction explicit helps an engineer assess the workflow. A responsive interface is useful, but the domain checks define the meaning of its result.
What the scale figure means
The event outcome has two parts:
| Measure | Scope |
|---|---|
| Students served | More than 5,000 students received on-duty attendance |
| Event window | The work occurred in under 10 days |
These figures describe use during the fest. They do not establish peak concurrency, requests per second, database throughput, or a latency percentile.
A student count and an internal operation count answer different questions. One grant required timetable and active-slot checks as well as the grant itself. Multiplying those steps can estimate activity, but it does not replace a measured request or database-operation count.
For this project, the clearest outcome is the one that maps to the university's task: students received the attendance they needed during the event window.
The checks that matter for this workflow
Timetable-dependent attendance creates a useful set of acceptance criteria. These are the behaviors a test plan should establish, rather than performance results inferred from event use:
| Scenario | Required behavior |
|---|---|
| The student has a relevant active slot | Apply the grant to that student's applicable slot |
| No active slot applies | Do not invent a slot or silently choose another one |
| Two students have different schedules | Evaluate each student's timetable independently |
| The same request is submitted again | Avoid duplicate attendance for the same student and slot |
| A required lookup fails | Return an unresolved or failed action instead of reporting success |
The final two cases are especially useful during an event. An uncertain response can lead an operator to repeat an action. A reliable workflow needs a clear distinction between a retry and a new grant.
The event's adoption figure alone cannot prove these properties. They need direct tests and records of the resulting state.
What I would measure in the next event
A more complete operational account would pair the student count with grant outcomes, rejected requests, duplicate attempts, and lookup failures. Latency measurements should cover the entire grant workflow as well as its individual stages.
That distinction would help separate a slow timetable lookup from a slow attendance write. It would also make a performance claim reproducible: a reader could see the measurement window and the operation being measured.
For privacy, aggregate operational measurements separately from student records. A public case study needs evidence of system behavior without revealing a student's schedule or attendance history.
The engineering lesson
This project made a university rule executable at event scale. The important unit of correctness was the attendance grant for a particular student and timetable slot.
The outcome was over 5,000 students served in under 10 days. The lasting design lesson is to model the real decision before optimizing how quickly the application can process it.
