Exam Management System
A high-integrity examination platform covering scheduling, seat planning, invigilation, script tracking, mark entry and controlled result publication.
- Stack
- 6 technologies
The problem
What needed solving
Examination workflows fail expensively and quietly: scheduling conflicts, duplicated seat allocation, unverified marks reaching publication, and mark changes that cannot be traced back to an actor.
My role
Responsibilities
System design and full-stack implementation: workflow state modelling, database constraint design, concurrency handling for mark entry, and the role-scoped front end.
The solution
Architecture summary
A transactional Spring Boot backend where examination integrity rules live in PostgreSQL constraints and explicit workflow states, with optimistic locking on mark entry and Redis caching for published read-heavy views.
Case study
In detail
Context
Examination systems are unforgiving. A scheduling conflict, a duplicated seat allocation or a silently overwritten mark is not a cosmetic defect — it is an integrity failure with consequences for real students, and it is usually discovered late.
The system was built around that constraint: make invalid states impossible to persist, and make every state change attributable.
Design decisions
Integrity in the database. Seat allocation, exam scheduling and mark entry are protected by unique and check constraints rather than by application logic alone. A double-booked room or a duplicate seat assignment fails at the database, not in a validation branch that a future refactor might bypass.
Explicit workflow states. Marks move through entry, verification and publication as distinct states with defined transitions. There is no path that publishes an unverified result.
Attributable changes. Every mark modification records who made it and when, so a disputed result can be traced rather than argued.
Controlled publication. Results become publicly visible only through an explicit publish action, which is also the point at which cached result views are invalidated.
Architecture
- Spring Boot with transactional service boundaries around each workflow transition
- PostgreSQL with composite unique constraints on scheduling and allocation
- Optimistic locking on mark entry to reject concurrent overwrites
- Redis caching for published, read-heavy result and schedule views
- Angular front end with role-scoped views for controllers, invigilators and mark entry staff
Outcomes
What changed
- Invalid scheduling and seat allocation states rejected at the database layer rather than in application branches
- Unverified marks structurally prevented from reaching publication
- Every mark change attributable to an actor and timestamp
- Concurrent mark entry conflicts detected and rejected instead of silently overwriting