FairRoom is a role-based room booking system that enforces fair access and prevents booking conflicts using a three-strike restriction rule with student and admin workflows.
System snapshot
Student room discovery and booking creation flows via React
Account-state/eligibility derivation from strike counts (good/warned/restricted)
Booking lifecycle management with conflict prevention and status transitions
Admin oversight flows for bookings, strikes, rooms, amenities, and analytics
Rust/Axum REST API backed by SeaORM + PostgreSQL entities (users, rooms, bookings, strikes, reminders, amenities)
Contract-first behavior via canonical OpenAPI (generated from the Notion API contract)
Design focus
Context
FairRoom exists to solve more than room reservation: shared-room misuse, late cancellations, no-shows, and booking conflicts create operational friction. The system is framed as a student/admin room booking platform where users can search rooms, create and manage bookings, view their own bookings and account standing, and become restricted when strike rules are triggered. Planning material in the FairRoom Notion hub defines the three-strike rule as a core business rule and establishes explicit scope boundaries, delivery checkpoints, and traceability expectations so the codebase enforces the intended policy rather than treating it as an optional UI feature.
Project parameters
Technology stack
Core Innovation
The key architectural move is that enforcement is not implemented as ad hoc UI checks; instead, the Notion API contract defines system-level behavior for account-state derivation, strike thresholds, booking eligibility rules, canonical statuses, and admin-only operations. The repository uses a generated OpenAPI artifact as an implementation-facing source of truth that stabilizes request/response shapes, enums, error classes, and endpoint responsibilities—so student flows, admin enforcement, and shared domain terminology remain consistent over time.
Implementation
The frontend is a React + Vite + TypeScript application with React Router and form validation via React Hook Form and Zod. It provides separate student and admin route experiences including authentication flows, room discovery and booking confirmation, viewing bookings and account status for students, and admin pages for bookings, strikes, room/inventory management, amenities, and analytics.
The backend is a Rust + Axum application using SeaORM with PostgreSQL persistence. It exposes a REST API surface secured with JWT bearer authentication and role claims, implemented across relational entities such as users, rooms, bookings, strikes, reminders, and amenities. The contract layer is explicitly emphasized: the Notion hub defines the canonical API contract, while contracts/fairroom.openapi.yaml is treated as the generated implementation artifact that stabilizes endpoint maps, status enums, and error types.
Latency profile
FairRoom operates as a conventional frontend-to-backend web system rather than a batch pipeline. Its runtime profile is shaped by authenticated REST requests, backend validation, relational persistence, and derived account-state checks that gate sensitive actions such as booking creation and strike-related operations.
System focus
The main operational concern is correctness of booking state and enforcement of fair access rules rather than raw throughput. Conflict prevention, strike thresholds, booking eligibility rules, and canonical status handling are central, supported by role-specific student vs admin surfaces and a shared contract that governs booking status values, reminder statuses, room statuses, and admin-only responsibilities.
Outcomes
The README indicates FairRoom has progressed from planning into a working full-stack implementation, including deployed frontend and backend URLs, student and admin route coverage, a Rust backend with Axum, a React frontend, and a committed OpenAPI contract artifact tied to the canonical Notion contract. It also emphasizes delivery discipline: scope, terminology, entity boundaries, and endpoint behavior are captured before being treated as implementation truth—aiming to improve testability, reasoning, and the ability to explain system behavior.
Why this matters
FairRoom matters because it demonstrates system thinking beyond building CRUD pages. The project’s value is in governed booking access: explicit rules for fairness and eligibility, bounded admin enforcement via role-specific surfaces, conflict-prevention and canonical state handling, and a planning hub that defines what the system is allowed to become. This combination of scope control, contract-first thinking, policy enforcement, and implementation alignment distinguishes it from a stitched-together booking demo.