CASE STUDY 05 / 05

LabFlow AI

Graduation project — in development

A lab and equipment booking system that never double-books: QR check-in, waitlist, maintenance, reports — later, ESP32 usage metering and an AI assistant that answers with citations. SWP391 → SEP490 capstone, FPT University.

There is no running build yet. What this page describes is the written plan, requirements and design — not finished features.

Status
In development — planning stage, coding starts 5 Oct 2026
Timeline
20 weeks: 5 Oct 2026 → 21 Feb 2027
Platforms
Web
Role
Solo, playing all five team roles C1–C5; code written by hand
01

Context & problem

Shared labs and equipment get double-booked, reserved and not used, borrowed without clear returns, broken with nobody logging it. The project tackles that with a hard goal: the database itself rejects every double booking.

The capstone is run like a client project: the whole plan, requirements, quality gates, risks and defence documents were on CT Work before the first line of code.

02

Who it serves

  • Students, lecturers

    Book labs, borrow equipment, join a waitlist when full.

  • Lab staff

    QR check-in, hand-over and return of equipment, maintenance logs.

  • Lab managers, administrators

    Resource catalogue, roles, usage reports, audit log.

03

Solution & key features

  • Booking without overlaps (planned)

    An exclusion constraint on time ranges, idempotency keys, optimistic locking; verified with 2/10/50 concurrent requests on real PostgreSQL.

  • Waitlist, QR, loans, maintenance (planned)

    A FIFO waitlist with holds and expiry; single-use QR codes; state machines for loans and maintenance.

  • IoT and AI — SEP490 phase (planned)

    ESP32 + current sensor → MQTT → usage sessions with automatic check-in/no-show; a pgvector RAG assistant with citations and a “say you don’t know” policy.

04

Architecture

  1. Client

    • React + TypeScriptBy role: student, lecturer, staff, manager, admin
    REST

  2. Application

    • Spring Boot 3Java 21 · Spring Security · JPA
    • MQTT consumerSEP490 phase
    Flyway migrations · JPA

  3. Data

    • PostgreSQL 16btree_gist: blocks double booking
    • pgvectorCited RAG

  4. Devices

    • ESP32Current sensor → MQTT
PLANNED architecture from the design documents — not built yet.
05

Hard technical decisions & trade-offs

01The database rejects double bookings, not an if statement

Problem
Two requests for the same slot arrive at once: check-then-write in application code lets both through.
Decision
An EXCLUDE USING gist constraint on half-open time ranges [start, end) — 9–11 and 11–13 do not overlap. The losing request gets error 23P01 and the API returns 409 with a waitlist suggestion.
Trade-off
Tied to PostgreSQL; the time range is copied into the item table because an exclusion constraint only sees columns of one table.

02Single-use QR codes, only the hash stored

Problem
QR codes get photographed or scanned twice.
Decision
UPDATE … WHERE used_at IS NULL: the second scan updates 0 rows. The database keeps only a hash of the token.
Trade-off
A lost code must be reissued; it cannot be recovered.

03Splitting work by vertical slice, not by layer

Problem
The course grades lines of code per member’s screens.
Decision
Each role owns a whole feature group from UI to database; 46 requirements (41 screens + 5 non-UI functions) are assigned to an owning role.
Trade-off
One person playing all five roles must switch context constantly.
06

Identified risks

No incidents yet — coding has not started. Instead, these are risks identified in the plan:

  • Scope creep
  • Learning Spring slower than planned
  • Burnout when working solo
  • Unstable IoT devices
  • Permission leakage through RAG, API or QR
  • Weeks 11–20 overlap with the internship
07

Measured numbers

No user, revenue or client numbers here — only what can be counted from source code and the database. Each row says how it was counted so you can check it. Anything that cannot be counted is not shown.

The plan on CT Work

Counted by command on the codebase on 04/10/2026

Weeks in the planlabflow-v2.json → weeks.length
20
Backlog requirementslabflow-v2.json → backlog.length (41 screens + 5 non-UI)
46
Epicslabflow-v2.json → epics.length
16
Test cases written up frontlabflow-v2.json → tests.length
41
Identified riskslabflow-v2.json → risks.length
10
Milestones / quality gateslabflow-v2.json → milestones.length
9
SEP490 report guidesNumbered files in docs/sep490
16
08

Technology

Back end (planned)
Java 21 · Spring Boot 3 · Spring Security · Spring Data JPA · Flyway
Data (planned)
PostgreSQL 16 · btree_gist · pgvector
Front end (planned)
React · TypeScript
Testing & ops (planned)
Testcontainers · Docker Compose · GitHub Actions · MailTrap
IoT (planned)
ESP32 · MQTT