Skip to content

Building a hotel platform, from booking engine to AI operating system

The hotel domain (PMS, CRS, channel managers, OTAs, rates and inventory), how its architecture evolves with scale, and where AI agents plug in without breaking the systems of record.

The domain: who owns which truth

Hotel software looks simple ("show rooms, take bookings") until you see how many systems must agree on one number: how many rooms of each type are still sellable on each night, at which price. Most of hotel architecture is about keeping that number correct across systems that each think they own it.

PMS · Property Management System
The hotel's operational system of record: reservations, room assignment, check-in/out, housekeeping status, folios (the guest's bill). Lives at or near the property.
CRS · Central Reservation System
Central inventory and rates across one or many properties. Distribution channels read availability from here and write bookings into it.
Channel manager
Pushes availability and rates to many sales channels (OTAs, GDS) and pulls their bookings back. Its job is avoiding overbooking when the same room is sold in ten places.
OTA · Online Travel Agency
Marketplaces like Booking.com or Expedia that sell rooms for commission. They hold a copy of your availability, which can be stale.
Booking engine
The hotel's own direct-booking website flow: search → room/rate selection → guest details → payment. Direct bookings avoid OTA commission (often 15–25%).
Rates & inventory
Inventory = rooms per room type per night. Rates = price per room type per night per rate plan (flexible, non-refundable, breakfast included…), plus restrictions (minimum stay, closed to arrival).
Payments
Authorisation at booking, capture at stay or cancellation-deadline, deposits, refunds, PCI DSS (Payment Card Industry Data Security Standard) scope. Usually delegated to a provider via tokenisation.
RMS · Revenue Management System
Recommends prices from demand forecasts, pickup and competitor rates. Writes rates into the CRS.

A direct booking, end to end

Click a component

Click any component to see what it does.

How the architecture evolves

A growing hotel-tech platform

An illustrative architecture for a hotel-technology company at each scale. Not a description of any specific vendor.

  1. 1
    Stage 1 · One hotel group's booking engine
    10 hotels · 50 bookings/day
    Next.js booking engineMonolith API (Django/Node)PostgreSQLPayment providerNightly PMS file sync

    A single database gives transactions for free: inventory and bookings change together. Nightly PMS sync is acceptable at this volume and avoids integration work.

  2. 2
    Stage 2 · Multi-property SaaS
    500 hotels · 5k bookings/day
    CDNLoad-balanced stateless APIRedis availability cacheQueue + workers for PMS/channel syncWebhooks from OTAsObject storage for photos

    Search traffic dwarfs bookings, so cache availability. PMS and channel integrations are slow and flaky: move them to background workers with retries and idempotency.

  3. 3
    Stage 3 · Distribution platform
    5,000 hotels · 100k bookings/day · 50M searches/day
    Search service with denormalised rate gridEvent streaming (Kafka) with outboxSeparate inventory, rates, reservations servicesRead replicasObservability (traces across integrations)Rate-limit + circuit breakers per PMS vendor

    Teams now own separate domains; integrations number in the hundreds. Events let new consumers (RMS, analytics, loyalty) join without touching the reservation path.

  4. 4
    Stage 4 · Multi-region, AI-assisted
    Global · peak 5k searches/s
    Multi-region read path, single-writer inventory per propertyData platform for revenue analyticsAI gateway + agents (concierge, booking, marketing, guest service)Policy engine + human approval for side effects

    Latency matters for global search, but inventory consistency matters more for writes: keep each property's inventory single-writer and replicate reads. AI joins as a client of the same APIs, not as a new source of truth.

Adding AI agents without breaking the systems of record

Four AI products a hotel platform might build. Each one is mostly context engineering plus tool design on top of the existing APIs:

  • AI concierge: answers guest questions ("is breakfast included?", "late check-out?") with over hotel policies, plus read-only tools for the guest's reservation.
  • AI booking agent: turns "a quiet room in Lisbon next weekend under €150" into searches, quotes and, after explicit confirmation, a booking.
  • AI marketing agent: drafts campaigns and segment ideas from aggregated booking data; a human publishes.
  • AI guest-service agent: handles requests (towels, taxi, complaints) by creating PMS tasks, escalating to staff when confidence or policy requires.
Click a component

Click any component to see what it does.

Engineering trade-offs

Real-time availability everywhere

  • No stale prices or phantom rooms
  • Simple mental model
  • Search load hits the CRS directly
  • Slow PMS/CRS APIs make search slow
  • Expensive at high look-to-book ratios
Choose when: Small inventory, low search volume, or the final reserve step only.

Cached availability for search, re-check on reserve

  • Fast, cheap search at scale
  • Protects the source of truth
  • Guests occasionally see a room that's gone at checkout
  • Cache invalidation logic to maintain
Choose when: Almost always for search; pair with a strict transactional re-check at reservation time.

Agent with direct database access

  • Fast to prototype
  • Bypasses validation, permissions and idempotency
  • One prompt injection away from data loss
  • No audit trail
Choose when: Never in production.

Agent through scoped tools on existing APIs

  • Same business rules as every other client
  • Per-tool permissions and approvals
  • Auditable
  • Tool design work up front
  • Some requests need new API endpoints
Choose when: Any agent that touches real bookings, payments or guest data.

Practical exercise

The last room on a sold-out night

It's New Year's Eve. One deluxe room is left. Within the same second, a guest books it on your booking engine and another guest books it on an OTA. Your channel manager pushes availability every 30 seconds. What happens, and how would you design to reduce and handle this?