PROJECT 02 / FULL-STACK SOFTWARE ENGINEERING
Restaurant Booking
& Operations
A Java web application designed to coordinate reservations, waitlists, and day-to-day restaurant workflows.
Problem and project scope
Restaurant reservations involve more than recording a time and a party size. Customers need a usable booking flow, while hosts and managers need consistent information about seating, waitlists, staff activity, and tables across a restaurant. In a five-person software engineering team, we built a Java web application that connects these workflows to a relational database.
This is an academic team project from 2025, developed using Java 17, Jakarta Servlets/JSP, Maven, Apache Tomcat, SQLite, and JDBC. The features below describe the shared application's implementation, not work claimed entirely by one team member.
How the application works
Customer reservations
A signed-in customer selects a restaurant, date, time, party size, and optionally a table. The servlet validates date/time inputs before sending the booking request to the database layer.
Seating and table availability
For a selected table, the DAO checks overlapping one-hour booking windows, ignores cancelled bookings, and creates the booking and table assignment in a single transaction.
Staff and waitlist operations
Staff-facing views display restaurant bookings and waiting guests. Hosts can enter walk-ins, and staff workflows support booking statuses and seating operations.
Manager reporting
Dashboard queries summarize total bookings, daily bookings, distinct customers, and counts by status. The DAO queries can be scoped to an associated restaurant.
The application in action
These are real screenshots from the locally running Java application, captured during an October 2026 walkthrough with fictional demonstration records. Each image is shown at its natural aspect ratio; select a screenshot to view it at full size.
All images show a local academic demonstration, not a publicly deployed reservation service. Records shown were confirmed fictional by the project contributor.
Architecture
The project follows a server-rendered web application structure: JSP pages present the interface; Java servlet handlers receive requests, validate input, and route operations; DAO classes work with SQLite via JDBC. Supporting filters and sessions provide role-aware access to administrative screens.
HTML / CSS / JavaScript→JSP + Servlets
Request handling→DAO / JDBC
SQL operations→SQLite
Application data
| Layer | Example components | Responsibilities |
|---|---|---|
| Presentation | JSP views, CSS, JavaScript | Booking forms, dashboards, floor plan |
| Request handling | BookingCreateServlet, StaffDashboardServlet | Validation, sessions, workflow routing |
| Data access | BookingDao, WaitlistDao, RestaurantTableDao | Queries, inserts, updates, table lookup |
| Persistence | SQLite, JDBC, DatabaseInitializer | Relational data, links, startup setup |
Database design
The initializer defines separate tables for restaurants, users, bookings, restaurant tables, waitlists, and roles. Junction tables represent booking-to-table assignments and user-to-role memberships, rather than storing multiple IDs in a single field.
Simplified relationships from the database initializer; additional tables, fields, and constraints are omitted for readability.
My engineering contributions
David Sanchez and I were the two primary coding contributors on this five-person project. The Git history documents my implementation and integration work across several parts of the application:
- Reporting and manager dashboards: added booking summary statistics and reporting views, then improved dashboard queries and restaurant-specific booking displays.
- Table management and planning: developed table viewing, editing, and planning flows; added delete and undo-delete actions; and built an initial visual floor-plan page.
- Employee administration: implemented employee management interfaces and backend operations for creating, editing, filtering, and sorting staff accounts.
- Staff and waitlist operations: connected restaurant bookings and waitlist data to staff dashboards, including staff-facing waitlist and table-assignment workflows.
- Application integration: fixed login and logout flows, reorganized JSP routing, and integrated protections into administrative forms.
- Reservation workflow refinements: improved time-slot and table-selection behavior and worked on the database booking-conflict path alongside David.
The shared booking code is a good example of our collaboration. An early version of the one-hour SQL overlap check appears in a commit by David; my subsequent reservation-workflow commit refined the method so it checks conflicts only when a particular table is selected, alongside updates to reservation time slots and table selection. The commit history establishes these contributions, but does not by itself prove who first designed every aspect of the check.
Design scope and future integration
The table planner uses a capacity-first greedy approach: it looks for one suitable table, then proposes a combination of eligible tables when necessary. In our local test, a party size of 12 produced tables 6, 7, and 8 (four seats each). The planner does not yet query date/time reservation conflicts, assign a proposed combination to a booking, or enforce physical adjacency. Connecting planning to reservation availability would be a natural next engineering step.
A separate idea was to support single-seat reservations at the bar. That was planned but not implemented; the floor-plan area labeled for bar seating should not be interpreted as a working bar-seat booking feature. Waitlist status and booking status were also managed through separate staff actions in the demonstrated flow.
Interesting engineering decisions
Preventing overlapping table bookings
Before assigning a specific table, BookingDao.createBookingWithTable queries for bookings whose one-hour occupancy window overlaps the requested period. The method uses setAutoCommit(false), commits the booking and link together, and rolls back on failure. This keeps the two inserts coordinated. It is a coursework implementation, not a claim of independently verified concurrency safety at production scale.
Validating dates and time slots
BookingCreateServlet checks that a booking date is not in the past and, for this project, restricts time selection to 11:30 AM–10:00 PM in 15-minute increments. Failed validation returns users to the form with an explanatory message.
Role-aware staff interfaces
The application distinguishes ADMIN, MANAGER, HOST, and EMPLOYEE roles. An authorization filter controls access to administrative routes, while individual staff servlets also check session and role information. This demonstrates application-level authorization logic, but the project has not been presented as a security-audited production service.
Team project and attribution
This was a five-person software engineering project. David Sanchez and I were the primary coding contributors, with other teammates also contributing. For example, Henry Le added an interactive table-plan implementation that extended the earlier floor-plan work. The architecture and system-wide features remain team accomplishments; the section above highlights contributions supported by my commits and pull requests, rather than claiming sole authorship of every class.
Next improvements: finish verifying that all demonstration account records in the public source repository are synthetic and safe to share before linking the repository from this page; consider adding a short annotated screen recording of the local reservation workflow.
What this demonstrates
- Full-stack Java web development across presentation, request-handling, and persistence layers
- Relational schema design with join tables and query-backed workflows
- Practical input validation, transaction handling, and role-aware interfaces
- Designing for realistic reservation, waitlist, and restaurant operations
- Collaborating on a substantial multi-module academic application