System architecture

How Lunchtable works end to end

A single SSR deployment handles the UI, API routes, and data access. Every booking and absence flows through one set of endpoints so coverage stays accurate for everyone viewing the board.

Client

Browser + React UI

The scheduling board renders in React with drag-and-drop, role filters, and coverage indicators. The UI polls to keep every viewer in sync.

App server

Astro SSR

Server-side rendering delivers the landing page and workspace quickly, then hands off to React for interactivity.

API

Bookings + Absences

Astro API routes accept schedule changes, apply coverage rules, and return the latest timeline state.

Data

PostgreSQL

Bookings and absences are stored in the database. Coverage calculations are derived on each refresh from the latest rows.

Data flow

Browser → SSR render → API read/write → PostgreSQL

Live updates

The board polls every few seconds to keep all views aligned without manual refresh.

Coverage rules

Tier minimums and day-type staffing logic are applied on every timeline refresh.

Deployment

Built as a standalone Node server with a single Postgres connection string.

Performance

Fast initial loads

SSR delivers a complete page quickly, then React hydrates for interactive scheduling.

Safety

Single source of truth

Every change passes through the API, so coverage math is consistent across all screens.

Operations

Minimal moving parts

One deployment, one database, and no background workers keeps ops simple.