Gonzalo Martin PerezAI Engineer | Software Engineer | Product Engineer

Case study · Jan – Dec 2025

Filomena: health-sciences exams across five institutions

A legacy CakePHP and jQuery monolith, rebuilt as an API-first platform that now runs high-stakes exams for five Argentine national institutions.

  • PHP
  • Laravel
  • React
  • Next.js
  • TypeScript
  • MariaDB
  • MySQL
  • Redis
  • Docker
  • GitHub Actions
  • Prometheus
  • Grafana
  • 5

    institutions in production

    UNS, UNRN, UNC, UNVM and FAMFyG.

  • 1,000+

    simultaneous users

    Observed in production with complete data consistency, not a synthetic benchmark.

  • <300 ms

    critical endpoints

    Average latency, through SQL tuning, Redis caching and queues.

  • 10 / 10

    final-year project

    Graded at Universidad Nacional del Sur.

One platform for the assessment lifecycle

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.

The problem

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.

Who it is for

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.

My contribution

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.

From monolith to API-first 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.

Architecture

Request path from the browser down, after the rebuild.

System

Exam platform architecture

The Next.js/React client uses one Laravel REST API backed by MariaDB and Redis for caching and asynchronous work. Prometheus and Grafana observe the database, queues and workers; Docker images are built and deployed through GitHub Actions. The diagram groups request handling and operational capabilities; the layer descriptions below explain each responsibility.
  1. ClientNext.js, React and TypeScript, serving administrators, evaluators and students.
  2. APIA Laravel REST API as the single contract for every client.
  3. DataMariaDB was the final database choice; MySQL was also used during the project. Index design and query tuning supported exam workflows.
  4. Cache and queuesRedis for caching and for asynchronous work.
  5. ObservabilityPrometheus and Grafana over the database, queues and workers.
  6. DeliveryDocker images built and deployed through GitHub Actions.

Explore the application

43 reviewed demonstration screens covering administration, student exams, evaluation and operational monitoring. Browse the workflows or enlarge a screen for a closer look.

Engineering decisions

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.

Isolation per institution

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.

Role checks on both sides

The API enforces role-based access control. The frontend reflects those permissions so users see the actions available to them.

Visibility into production

Prometheus and Grafana provide visibility into production behavior across the database, Redis, queues and workers, supported by structured logging and health checks.

What changed

The first version compared with the platform now in production.
AspectBeforeAfter
ArchitectureCakePHP and jQuery monolithLaravel REST API with a Next.js frontend
ConcurrencySequential, single-institution delivery1,000+ simultaneous users, observed in production
LatencyDegraded under concurrent loadCritical endpoints below 300 ms on average
OnboardingRequired development workConfiguration, in minutes
Access controlInconsistently enforcedMulti-role RBAC across API and frontend
ObservabilityNonePrometheus and Grafana

Delivery and operation

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.

Production results

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.

Next engineering priorities

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.

Evidence

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.