Drunk Cherry
A reservation platform for the Drunk Cherry restaurant — guests pick their exact table on an interactive floor plan, and staff manage reserved and blocked seating from a dedicated panel.
My Role
Tech Lead — led delivery at Koober Coders: the guest reservation flow, the interactive table map, and the staff-side seating management panel.
Project Type
Client Project — restaurant reservation system with interactive table selection.
Tools Used
Interactive floor-plan table selection, staff panel for reserved and blocked seating, reservation management
Live Link
https://drunkcherrygudauri.com
Problem & Solutions
Choosing a Table, Visually
Problem
Phone bookings lose the one thing guests actually care about: where they will sit. Describing a floor plan over the phone satisfies nobody.
Solution
An interactive floor plan lets guests see the room and reserve the specific table they want — the reservation becomes the seat, not a note.
The Floor Belongs to the Staff
Problem
A restaurant floor is not static — tables get blocked for maintenance, held for walk-ins, or grouped for events, and staff need that state at a glance.
Solution
The staff panel manages both reserved and blocked seating on the same live map, so the floor plan guests book against always reflects reality.
Double Bookings Are Not an Option
Problem
When guests and staff both change the floor plan, two reservations for the same table at the same time are one race condition away — and in a restaurant, that mistake happens in front of the guest.
Solution
Reservations and staff blocks are validated against the same table-and-time model on the server, so a table taken for a slot becomes unavailable everywhere the instant it is claimed.
Architecture
Guests and staff work on the same table-and-slot model: the reservation app books, the staff panel blocks and holds, the API validates both against the database.
Decision log
The calls that shaped the build — what was decided, why, and what it cost.
One table-and-slot model for guests and staff
Decision. Validate guest reservations and staff blocks against the same server-side model.
Context. Two clients changing the same floor plan is one race condition away from a double booking in front of a guest.
Consequence. A table taken for a slot is unavailable everywhere the instant it is claimed; the floor plan can never show two truths.
The floor plan is the interface
Decision. Let guests pick a table on an interactive map rather than a form with a party size.
Context. Phone bookings lost the one thing guests cared about: where they would sit.
Consequence. The reservation becomes the seat, not a promise; the map needs a maintained layout per room.