Request a table
The public form validates event and seating choices before creating a UUID-tracked pending reservation.
FiredOrder up · service night
A reservation system that runs like the pass.
Guests request a table without an account, staff review and approve from a filtered queue, and a token-secured REST API exposes the same operations downstream.
Order #0412 Guest reservation
>Requested [ pending ] >Reviewed [ staff ] >Served [ approved ]
Host stand note
This split shaped the whole system: public intent first, protected operations second.
The brief
Two rooms, one ticket.
A reservation platform serves two very different rooms. Guests want a seat with zero friction. Staff want control, filters, and a record of every call. The job was to let both work the same ticket without handing the wrong controls to the wrong person. I owned the multi-module architecture, the auth and validation layers, and the dining room model; Matheus built the event and reservation flows and the email confirmation service.
Room 01 Front of house
The guest
Browse events and seatings, request a table, and get a confirmation code. No account, no friction.
Room 02 Back of house
The staff
Sign in, filter the queue by event and status, assign a table, then approve or deny. Every call is logged.
Palette
Warm room, cool contrast.
Portfolio cream and charcoal hold the page together, while cinnamon, coffee, apricot, and blue-grey accents add the restaurant tone.
Service choreography
A reservation moves like a ticket through service.
Send confirmation
EmailService sends the guest a formatted confirmation with event, seating time, and confirmation code.
SentFilter the queue
The dashboard narrows reservations by event and status so staff can work the next service window.
QueuedAssign a table
Authenticated users review full guest details and attach a valid dining table before approval.
PlatedExpose operations
The separate REST app uses bearer tokens and OpenAPI docs for third-party access.
ServedThe surfaces
Four rooms, one house.
Guests reserve without an account, staff work the queue behind a login, and integrators read a documented API. Different rooms, the same domain underneath.
01
Guest surface
The reservation book
The guest flow keeps attention on event, seating, and contact details. It behaves like a host stand: collect the request, confirm the code, then move the ticket into the queue.
guest/reservation
02
Staff surface
The service queue
Staff do not need every record at once. They need the next decision. Event and status filters turn the reservation list into a working queue.
staff/reservations
03
Security surface
The locked staff door
The login screen marks the boundary between public browsing and operational authority. That boundary matters because approvals change the guest experience.
security/login
04
Integration surface
The documented API
Swagger turns the backend into something reviewable. The API is secured with JWT bearer tokens and kept separate from the Thymeleaf web app so future clients, a mobile app or a partner system, can consume the same domain without touching the staff interface.
api/swagger
Console // Seating Stand
Host Stand Seating Simulator.
Interact with the reservation pipeline to see how guest requests, seating validation, and table assignments coordinate in real-time.
Architecture
One system, wired like infrastructure.
01 Clients
Staff browser
front of houseAPI client
third-party02 Delivery apps
app-web
Thymeleaf : 8080restaurant-api
REST : 8081auth-api
tokens : 808203 Domain modules
restaurant
events · reservationsauth
access04 Shared foundation
common
domain · application · web · infrastructure05 Persistence
MySQL
Spring Data JPATechnical Mise en Place
The stack follows the service boundary.
Application base
Runtime, framework, and module boundaries.
Module // common-domain · common-infrastructure- Java 21
- Spring Boot
- Maven (Multi-Module)
Security boundary
Staff login and token-secured API access.
Module // auth-domain · auth-application- Spring Security
- JWT / OAuth2
Persistence
Reservation, seating, menu, and event data.
Module // restaurant-persistence- Spring Data JPA
- MySQL
Delivery surfaces
Staff screens, responsive UI, and API documentation.
Module // app-web · app-restaurant-rest-api- Thymeleaf
- Bootstrap 5
- Swagger / OpenAPI
Built for service
Proof the service holds.
Architecture
Multi-Module Clean Architecture
Maven multi-module project with shared common libraries. Each module (restaurant, auth, common) has its own Domain, Application, Infrastructure, and Presentation layers with strict dependency inversion.
Rules
Validation Framework
Custom ValidationService pattern per entity with Result/ValidatedResult wrapper types, field-level error binding to BindingResult, and dedicated validation services for Events, Seatings, Menus, MenuItems, DiningTables, and Reservations.
Dining room
Seating & Dining Table System
Seating CRUD with table assignments (many-to-many via SeatingTableEntity), capacity tracking, overlapping seating conflict detection, and cascade delete management.
Service prep
Data Initialization Service
InitializeDataServiceImpl seeds the database with default dining tables, events, seatings, menus, and menu items on first startup, enabling immediate demo readiness.