Tavola — Multi-Tenant Restaurant Reservation Platform

Tavola is a reservation platform for restaurants. Restaurants manage reservations, tables and floor plans, branches, employees, menus, offers, subscriptions and analytics through one backend; customers discover restaurants, book tables, join waitlists and receive notifications in a mobile app; platform operators manage the whole network from a separate console.

A reservation system is only useful if its state is correct under concurrency: a table cannot be promised twice, a waitlist must advance in order, and staff on the floor must see changes as they happen. On top of that, one deployment has to serve many restaurants without any of them seeing another's data.

Tenant isolation for every request; four distinct actors (customer, restaurant staff, restaurant owner, platform admin) with separate authentication paths; multiple languages and currencies as design goals; and live operational updates that must pass through a reverse proxy.

The work was planned documentation-first: architecture, domain model, database design and a development roadmap were completed before implementation, and binding choices are recorded as architecture decision records. Implementation then proceeded module by module — infrastructure, authentication, authorisation, tables, the reservation engine, real time, notifications — each closed with its own verification.

A modular NestJS application exposes a versioned REST API (/api/v1) behind Nginx. PostgreSQL is accessed through Prisma with a controlled migration policy; Redis provides sliding-window rate limiting and the Socket.IO adapter for live table and reservation updates; BullMQ runs durable background work; MinIO stores media. Push notifications go through OneSignal.

Clients are separate applications: a Flutter customer app (GetX, feature-based MVC, a Dio client with bearer refresh and a guest mode), a React 19 + TypeScript restaurant dashboard with English/Arabic and dark/light themes, and a standalone platform-owner console that authenticates only against the platform-admin endpoints.

Authentication uses JWTs with refresh-token families and server-side sessions, so a stolen refresh token can be detected and a whole family revoked. Authorisation is a separate layer of RBAC policies, permission resolution and scope guards — being signed in and being allowed are different checks.

Platform administration has its own login and token type rather than a privileged restaurant role, which keeps the platform-operator surface out of the tenant authentication path entirely.

The table module supports moving, merging and splitting tables while reservations reference them; the reservation engine covers approval, lifecycle, phone and walk-in bookings, waitlists and operational signals. Real-time delivery had to be verified end-to-end through Nginx, not only in-process.

As reported in the backend repository: the table module (including merge and split) and the reservation engine are implemented and live-verified; the WebSocket layer is verified through Nginx; and the notification system passes a strict end-to-end suite of 34 suites / 377 tests.