Crystal Ski Rental

Checking for a clash and then inserting is two statements, and two customers booking the same pair at the same moment can both pass the check. So the rule lives in Postgres as an exclusion constraint over the ski and the date range, partial on items that still hold their dates. The API check only exists to explain the ordinary case; the constraint is what is actually true.

ALTER TABLE "reservation_item"
  ADD CONSTRAINT "reservation_item_no_overlap"
  EXCLUDE USING gist (
    "skiId" WITH =,
    -- '[)': start inclusive, end exclusive, matching the rest of the app.
    daterange("startDate", "endDate", '[)') WITH &&
  )
  WHERE ("holdsDates");

Prices are Decimal(10,2) in Postgres, strings in the API and decimal.js in arithmetic; a JavaScript number never holds a price. The search, the basket and the booking all quote through one function, so the price on the card is the price saved, and the reservation keeps a snapshot a later price change can never rewrite.

export const DISCOUNT_TIERS = [
  { fromDays: 1, toDays: 3, percent: 0 },
  { fromDays: 4, toDays: 6, percent: 10 },
  { fromDays: 7, toDays: 10, percent: 15 },
  { fromDays: 11, toDays: 19, percent: 20 },
  { fromDays: 20, toDays: 30, percent: 25 },
] as const;

A date picked in a calendar is local midnight, which toISOString turns into the previous day anywhere east of Greenwich. Dates travel as YYYY-MM-DD strings, become UTC at the server, and ranges are half-open, which is what lets one rental end on the day the next begins.

Page guards redirect a signed-in user who is in the wrong area to their own, so a stale bookmark is never a dead end. But pages are not data: every API procedure carries its own role level, and sign-up cannot smuggle in a role.

Each tRPC endpoint says who may call it, what it accepts, and makes one call into a service. Services are wired in a dependency container and never read the session: whoever is acting is passed in, so authorisation stays next to the role check.

The reservation lifecycle and the rating windows are plain functions with table-driven tests. The server enforces them and the screens import the same functions to decide which buttons to show, so a screen never offers an action the server would refuse.

Filters, sorting, pages and tabs are query parameters, so any view can be reloaded, shared and bookmarked. The URL is untrusted input, parsed with the same Zod schema as the API, and a parameter that does not survive is dropped on its own.