Ruby's Plate

The Problem

Small restaurants manage reservations through phone calls and paper notebooks — leading to double bookings, lost reservations, and no data for analyzing peak hours or popular table configurations.

The Solution

I built Ruby's Plate as a web-based reservation system with role-based access for customers and restaurant admins.

• Reservation scheduling — Customers pick date, time, party size, and optional seating preferences. The system prevents double-booking by checking availability in real-time.
• Secure authentication — Session-based auth with hashed passwords and CSRF protection.
• Admin dashboards — Reservation overview, daily/weekly views, and basic analytics (peak hours, average party size).
• Normalized PostgreSQL schema — Designed for efficient queries on availability checks and reporting aggregations.

What Went Wrong

The initial availability check queried all reservations for a given date and filtered in Ruby, which was slow for restaurants with high reservation volume.

The fix: I moved the availability logic into a PostgreSQL query with proper indexing on (date, time_slot, table_id), reducing the check from O(n) Ruby filtering to an indexed database lookup.

Results

• Eliminates double-booking with real-time availability checks
• Admin analytics for operational insights
• Efficient PostgreSQL schema with indexed availability queries