A full rewrite of my senior capstone: students book 5 to 45 minute office-hour slots, and faculty set their hours, closures, booking rules, and approvals. Undo, reminders, ratings, and a waitlist are built in.
A student needs five minutes to check a grade. Another needs forty-five for a project review. Both are chasing the same weekly office hour, often with no idea which slots are still open. One walks across campus for a time that was taken an hour earlier; a faculty member sits in an empty room because a cancellation was never offered to anyone else.
Faculty end up running the queue by hand: cap how many students they see, close for a meeting, turn away a request that came too late, approve or decline another, and remember to send a reminder. A shared spreadsheet, a whiteboard, or an email thread leaves everyone guessing how long a meeting should be, whether the room is free, and who is next.
v2 turns that manual queue into the product. Faculty publish their weekly hours, set session lengths and rules, close a day when something comes up, and approve requests. Students see the real open slots, book one, cancel and undo for a few seconds, and join a waitlist when the time they need is full. Reminders and ratings close the loop.
React 19, TypeScript, Vite, React Router, and TanStack Query run the front end. The API is plain PHP 8.4 with no framework: a router, controllers, services, and repositories over PDO. MariaDB 11.4 holds 13 tables, and the API exposes 46 REST endpoints, 28 of them writes.
That is more structure than the first version had, but it is what makes the rules testable. The service layer owns the transaction and the checks; the controllers only validate input and shape the response.
A booking locks the student row, then the faculty row, always in that order, and checks notice, overlaps, limits, closures, and the rest before it writes. The order is deliberate: it cannot deadlock, and it gives one winner under contention.
Trade-off: a little more work per booking, in exchange for a rule set that cannot half-apply. An eight-student race for one slot produces exactly one booking.
A cancelled time is held for 15 seconds on the server; the interface offers 10. Undo does not restore a saved booking blindly. It runs the same checks under the same locks, so a slot that was taken in the meantime stays taken.
Trade-off: a short hold on the slot, in exchange for undo that cannot create an overlap. An undo racing seven bookings still wins.
Each reminder is claimed with a conditional update, so it is created once. Optional email goes through an outbox, is scheduled ahead, and is skipped if the reason for it has gone.
Trade-off: a little scheduling machinery, in exchange for a reminder path that survives retries without sending twice.
339 PHPUnit tests, 143 Vitest tests, and 20 Playwright tests run in CI, with accessibility checks in light and dark. The booking race test was proven by removing the lock: without it, it produced double bookings.
Trade-off: a slower pipeline, in exchange for deploy gates that catch the failures that matter.
The full feature set and the engineering behind it, including booking correctness, reminders, security, and testing.
Let's talk it through and build it together.