Hospitality Booking Platform

• Each night is claimed with INSERT … ON CONFLICT DO UPDATE … WHERE isBooked = false
• The second concurrent request waits on the row lock, then fails the condition and gets 409 Conflict
• Paying with hotel credit locks the balance row (SELECT … FOR UPDATE) so one balance can't fund two bookings
• Verified with scripts that fire parallel booking requests

Booking created (PENDING)
  └─► publish to delay queue (TTL 15 min, no consumer)
        └─► TTL ends → dead-letter exchange → booking.expiry.process
              └─► consumer: still PENDING? → EXPIRED, release room, emit socket

• The consumer is idempotent: already-paid bookings are ignored
• A payment arriving after expiry doesn't revive the booking; it's flagged for manual refund instead

• The webhook routes by order-id prefix (BK- for bookings, FO- for food orders); unknown prefixes still get 200 so gateways don't retry forever
• Midtrans, DPAY, and PayPal all funnel into a single applyGatewayStatus function
• PayPal doesn't accept IDR: bills are converted to USD server-side, and webhook payloads are only a trigger. Status and amount are re-fetched from PayPal and matched against the bill
• Status changes are pushed over Socket.IO, with 5-second polling as a fallback while pending

For each night:
  1. Find the APPROVED proposal for the branch covering that date
  2. Start from the room type's base price
  3. Apply matching rules (WEEKEND / SPECIFIC_DATE / DATE_RANGE) by priority
  4. Apply APPROVED adjustments (latest wins; per-room beats all-rooms)
Total = Σ nightly prices → stored on the booking item

• Maker-checker: managers create proposals and adjustments, owners approve them; overlapping periods are rejected
• Prices are locked into the booking, so later changes never affect existing bookings
• Room types without a proposal are hidden from the public, so guests never see a room they can't book
• Refactored from 'check-in price × nights' to per-night sums, because one stay can span weekends or promo dates

• The new booking starts PENDING while the old one stays active until the difference is paid, so a failed payment never costs the guest their room
• Paid → old booking cancelled and released; expired → new room released, old booking untouched
• Settlement runs from every path that can change status, with row locks and conditional updates so concurrent processes don't overwrite each other
• A negative difference goes straight to the guest's hotel credit

• A policy is a day range before check-in + refund percentage + allowed payout type; ranges are validated not to overlap
• Preview issues a 15-minute token holding the refund amount, and confirm redeems that token
• Credit refunds land instantly; cash refunds go through approval

• After admin approval the backend mints the token to the guest's wallet via TreasuryCap
• The IDR rate is total IDR backing ÷ total tokens minted, with a backing log
• Token payments are verified by a transfer listener or a client-submitted transaction digest, idempotent per digest

• Converted prices are marked ≈ with a tooltip showing the rate and its timestamp
• A daily job fetches rates, keeps the last good rate on failure, and supports a manual lock
• Each booking stores a server-computed snapshot: currency, amount, rate, and rate time
• Language and currency live in cookies, so SSR pages render correctly with no hydration mismatch

• Paths resolve in a canonical order (location → type → facet); aliases and other orders 301 to the canonical path
• Unknown segments return a real 404, not a soft 404
• Branch and room-type slugs share one namespace so a segment never has two meanings
• Listings with fewer than 2 rooms get noindex, follow and are left out of the sitemap

Request ─► ① Auth (JWT + DB session) ─► ② Endpoint guard ─► ③ Service check (role level, branch scope) ─► data
Dashboard ─► ④ Menu access control (only decides what's shown)

• Roles and branches are re-read from the database, so changes apply without re-login
• A clear split between visible menus (UX) and endpoint permissions (security)

• Password login once per device, then a mandatory 6-digit PIN (weak PINs rejected)
• Unlock by server-checked PIN (device revoked after 5 failures) or fingerprint
• Auto-lock on idle or background, refresh tokens rotated on every use

• A FastAPI agent calls an LLM through OpenRouter and uses the backend's public endpoints
• Chat bookings go through the same booking flow as the web, so no business rule is duplicated
• Conversation context and history are stored per number; the WhatsApp webhook is in place