βββββββ βββββββ βββββββββββ βββ βββ ββββββ βββββββββββ
ββββββββββββββββ βββββββββββ βββ βββ βββββββββββββββββββ
βββ ββββββββββββ βββββββββ βββ βββ βββ ββββββ ββββββ
βββ ββββββββββββββββββββββ βββ βββ βββ ββββββ ββββββ
ββββββββββββββ ββββββββββββββ βββββββββββββββββββββ βββββββββββ
βββββββ ββββββ βββββββββββββ ββββββββ βββββββ βββ βββββββββββ
- Distributed Mutex Concurrency Protection: High-velocity table reservation endpoints are guarded by Redis distributed key locks (
SET lock:table:{id}:{slot} token NX EX 10) paired with atomic Lua scripts, eliminating race-condition double-bookings during peak dining rushes. - Dual-Tier Concurrency Defense: Enforces PostgreSQL row-level locks (
SELECT FOR UPDATE) and composite unique constraints on(table_id, time_slot)to guarantee zero double-allocations even during cache failover or network partitions. - Full-Stack Monorepo Architecture: Clean separation of concerns across Express.js backend services, shared TypeScript domain types, and a Next.js 14 App Router customer portal and staff Kitchen Display System (KDS).
- 25 Production Business Modules: Complete lifecycle coverage including
bookings,tables,floor-layout,kitchen,orders,menu,inventory,delivery,payments,analytics, andstaff. - Resilient Cache Failover: Custom
ResilientRedisclient featuring automatic in-memory fallback stores to guarantee zero API process crashes during transient network disconnects or Redis maintenance. - Zod-Powered Schema Validation: Strict payload sanitation and type safety on all reservation times, party sizes (1β20), item selections, and status transitions before touching persistence layers.
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β CLIENT / USER PORTALS β
β βββββββββββββββββββββββββ βββββββββββββββββββββββββββββ β
β β Customer Web & POS UI β β Kitchen Display / Waiters β β
β β (Next.js 14 App) β β (Real-Time Order View) β β
β βββββββββββββ¬ββββββββββββ βββββββββββββββ¬ββββββββββββββ β
ββββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββΌβββββββββββββββββ
β HTTP / JSON API β
βΌ βΌ
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β DINE LUXE REST API GATEWAY (Express) β
β β
β ββββββββββββββββββββββ ββββββββββββββββββββββ ββββββββββββββββ β
β β Auth & RBAC β β Payload Validation β β Rate Limiter β β
β β (JWT / Bearer) β β (Zod / CJS) β β (Redis-backedβ β
β βββββββββββ¬βββββββββββ βββββββββββ¬βββββββββββ ββββββββ¬ββββββββ β
β β β β β
β βββββββββββΌβββββββββββββββββββββββββΌββββββββββββββββββββββΌββββββββ β
β β BUSINESS CONTROLLERS β β
β β β’ Bookings / Table Allocator β’ Orders & KDS Dispatcher β β
β β β’ Menu & Dynamic Pricing β’ Inventory & Stock Depletion β β
β βββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ¬ββββββββ β
βββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββββββββΌββββββββββββ
β β
βΌ [SET NX EX 10 / Lua Release] βΌ [SQL / Prisma]
βββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββ
β REDIS DISTRIBUTED LOCK β β POSTGRESQL 16 DATABASE β
β β’ Mutex key per table/slot β β β’ Row-lock FOR UPDATE β
β β’ Sorted-set reminders β β β’ Relational integrity β
β β’ In-memory safe fallback β β β’ B-Tree index lookups β
βββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββ
During peak reservation windows (e.g., Valentine's Day or Friday evening dining), simultaneous requests for the same table at the identical time slot must never result in an overbooked table.
Before executing any database write, the service attempts to acquire an exclusive lock:
const lockKey = `lock:table:${tableId}:${slot}`;
const lockAcquired = await redis.set(lockKey, token, 'PX', 10000, 'NX');
if (!lockAcquired) {
throw { statusCode: 409, message: 'Table is currently being reserved by another guest' };
}Releasing the lock requires cryptographic token verification to prevent a slow transaction from accidentally deleting a lock re-acquired by another client:
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
endSELECT id, status, capacity
FROM tables
WHERE id = p_table_id
FOR UPDATE;The system is normalized across 8 core relational entities:
| Table | Primary Key | Key Foreign Keys & Indexes | Description |
|---|---|---|---|
users |
id (UUID) |
email (UNIQUE) |
Customer and staff profiles with hashed credentials |
tables |
id (UUID) |
branch_id, status, capacity |
Floor tables with seating capacity and physical status |
menu_items |
id (UUID) |
category_id, is_available |
Menu catalog with item descriptions and pricing |
orders |
id (UUID) |
table_id, user_id, status |
Active dining orders and payment totals |
order_items |
id (UUID) |
order_id, menu_item_id |
Individual order line items with customization notes |
reservations |
id (UUID) |
(table_id, time_slot) UNIQUE, user_id |
Booked dining slots with state tracking |
payments |
id (UUID) |
order_id, transaction_ref |
Payment records, payment method, and receipts |
audit_logs |
id (UUID) |
user_id, action, created_at |
Immutable security audit trail of staff actions |
POST /api/reservationsβ Create a table booking (guarded by Redis distributed lock).GET /api/reservationsβ List reservations with pagination and status filters.GET /api/reservations/:idβ Retrieve reservation status and assigned table details.DELETE /api/reservations/:idβ Cancel a confirmed booking and release the table.
POST /api/ordersβ Create a customer order for an occupied table.GET /api/orders/:idβ Get full order receipt and kitchen preparation progress.PATCH /api/orders/:id/statusβ Advance KDS workflow (PENDINGβPREPARINGβREADYβSERVED).
GET /api/menuβ Retrieve full menu items filtered by category and dietary flags.POST /api/menuβ Add a new menu item (admin / manager only).
Dine Luxe includes automated unit and integration tests covering reservation locking, schema validation, conflicting slot detection, and status workflows:
# Run the test suite
npm testβΆ Dine Luxe API Test Suite
β 1. Valid reservation creation succeeds with 201 Created (18.3ms)
β 2. Reservation with invalid party size returns 400 Bad Request (2.8ms)
β 3. Reservation with missing customerName returns 400 Bad Request (2.6ms)
β 4. Duplicate reservation for identical table and timeSlot returns 409 Conflict (3.4ms)
β 5. Redis Lock: client cannot release lock owned by different token (0.5ms)
β 6. Reservation cancellation updates status to CANCELLED (3.5ms)
β 7. Menu listing and category filtering works (3.7ms)
β 8. Order creation and Kitchen Display status updates succeed (3.4ms)
β Dine Luxe API Test Suite (42.3ms)
βΉ tests 9
βΉ suites 0
βΉ pass 9
βΉ fail 0
- Node.js: v18.0.0 or higher
- pnpm or npm
- PostgreSQL 16 (or Supabase project)
- Redis (optional; in-memory fallback enabled automatically if offline)
git clone https://github.com/ronitgupta138/dine-luxe.git
cd dine-luxe
pnpm install # or npm installcp .env.example .env
cp backend/.env.example backend/.env# Start backend and frontend simultaneously via Turborepo
npm run dev
# Or run tests
npm test- π Frontend Web Application (Vercel):
πhttps://dine-luxe.vercel.appβ Production restaurant operating system featuring customer table reservation, staff kitchen display system (KDS), cashier billing, and floor maps. - β‘ Backend REST API (Render):
πhttps://dineluxe-backend.onrender.com/healthβ High-throughput Node.js/Express REST API connected to managed PostgreSQL 16 (dineluxe_db).
Distributed under the MIT License. See LICENSE for full details.
Crafted with precision by Ronit Gupta
Computer Science & Business Systems Undergraduate β’ SDE-1 / Backend Engineer