Pseudonymity as a data-model property
Students are pseudonymous to evaluators. The data model and API enforce that boundary, keeping student identity separate from the evaluator's assessment workflow.
Case study · Jan – Dec 2025
A legacy CakePHP and jQuery monolith, rebuilt as an API-first platform that now runs high-stakes exams for five Argentine national institutions.
5
institutions in productionUNS, UNRN, UNC, UNVM and FAMFyG.
1,000+
simultaneous usersObserved in production with complete data consistency, not a synthetic benchmark.
<300 ms
critical endpointsAverage latency, through SQL tuning, Redis caching and queues.
10 / 10
final-year projectGraded at Universidad Nacional del Sur.
Filomena supports exam preparation, scheduling, delivery and assessment for health-sciences institutions. Administrators configure exams and access, students work through clinical cases, and evaluators assess answers against structured rubrics.
The product brings those workflows together while separating institutional data and protecting student identity in the assessment process. Its 43-screen demonstration below follows those roles through the application.
Health-sciences degrees assess students through large, high-stakes written exams. Filomena's first version was a CakePHP and jQuery monolith built for a single institution. Performance degraded under concurrent load, exam delivery was sequential, access control was enforced inconsistently, and adding an institution meant writing code.
The original platform lacked proactive monitoring. The rebuild added visibility into application performance and the services supporting exam delivery.
Three roles with genuinely different needs. Administrators configure institutions, courses and schedules. Evaluators author questions and review results. Students sit the exams, and they must remain anonymous to the evaluator grading them.
Those roles are not mutually exclusive. A professor can be an evaluator in one course and an administrator in another, which is why role handling had to be multi-role from the start rather than a single field on a user.
I was the principal author and contributor in a three-person final-project team at Universidad Nacional del Sur. My work covered architecture, backend, frontend, infrastructure, security, observability and coordination.
We delivered iteratively with Agile practices and Trello, bringing together institutional requirements and the implementation of a working product.
We separated the CakePHP and jQuery monolith into a Laravel REST API and a Next.js, React and TypeScript frontend. The API provided a common contract for the interface and multi-institution workflows, with input validation and role-based access control. Server-side rendering supported the initial page load, followed by interactive application flows.
SQL tuning, indexes, Redis caching and queues supported concurrent exam workflows. Prometheus and Grafana made production behavior visible across the application and its supporting services.
Request path from the browser down, after the rebuild.
System
43 reviewed demonstration screens covering administration, student exams, evaluation and operational monitoring. Browse the workflows or enlarge a screen for a closer look.
43 / 43











































Students are pseudonymous to evaluators. The data model and API enforce that boundary, keeping student identity separate from the evaluator's assessment workflow.
Each institution manages its own courses, evaluators, students, exams and schedules, with data isolated between them. This is what turned onboarding a new institution from development work into configuration.
The API enforces role-based access control. The frontend reflects those permissions so users see the actions available to them.
Prometheus and Grafana provide visibility into production behavior across the database, Redis, queues and workers, supported by structured logging and health checks.
| Aspect | Before | After |
|---|---|---|
| Architecture | CakePHP and jQuery monolith | Laravel REST API with a Next.js frontend |
| Concurrency | Sequential, single-institution delivery | 1,000+ simultaneous users, observed in production |
| Latency | Degraded under concurrent load | Critical endpoints below 300 ms on average |
| Onboarding | Required development work | Configuration, in minutes |
| Access control | Inconsistently enforced | Multi-role RBAC across API and frontend |
| Observability | None | Prometheus and Grafana |
Our three-person team used Agile practices and Trello to coordinate requirements, implementation and release.
Docker and Docker Compose provided containerized environments, while GitHub Actions ran production deployments in under fifteen minutes, from push to live. The public code repositories are snapshots and do not include the original deployment pipeline.
Filomena is active at UNS, UNRN, UNC, UNVM and FAMFyG. Production operation showed 1,000+ simultaneous users with complete data consistency and critical endpoints below 300 ms on average, monitored through Prometheus and Grafana.
The final project received 10/10 at Universidad Nacional del Sur, alongside university interviews, coverage and mentions from academic authorities.
The next iteration would prioritize automated regression coverage for concurrent exams and permission boundaries. The public snapshots currently contain framework smoke tests.
I would also preserve repeatable performance scenarios alongside each release, so future changes can be compared with the production behavior already observed.
The product walkthrough and engineering context are included on this page. The linked repositories are public source snapshots; they document the implementation, not the original development history or deployment pipeline.