The travel technology stack is one of the most complex in any industry: real-time inventory that expires the moment it's not booked, globally distributed users, multiple distribution channels (OTA, direct, corporate, GDS), complex pricing algorithms, and revenue management requirements. This guide covers how Zyllo Tech engineers booking platforms that serve hotels, hotel chains, and travel aggregators.
How is a hotel booking engine structured?
A booking engine has four distinct functional planes that must scale independently:
- Availability plane: real-time room inventory, occupancy calendars, rate plan availability. Read-heavy; cached aggressively but must be accurate.
- Pricing plane: best available rate (BAR) calculation, promotions, package rates, corporate rates. Must be deterministic and auditable.
- Reservation plane: booking creation, modification, cancellation. Write-heavy; must be transactionally safe.
- Distribution plane: channel manager integration (OTAs, GDS, direct). Event-driven to push inventory and rate changes to all channels.
GET /v1/availability?propertyId=htl_912&checkIn=2026-11-14&checkOut=2026-11-17
&adults=2&children=1¤cy=INR
200 OK
{
"propertyId": "htl_912",
"nights": 3,
"roomTypes": [{
"code": "DLX-KING",
"name": "Deluxe King",
"available": 4,
"ratePlans": [
{ "code": "BAR",
"total": 2145000, "currency": "INR", // minor units
"perNight": [715000, 715000, 715000],
"restrictions": { "minLOS": 2, "closedToArrival": false },
"cancelBy": "2026-11-12T18:00:00+05:30" },
{ "code": "EARLYBIRD",
"total": 1823250, "derivedFrom": "BAR", "formula": "BAR * 0.85" }
]
}]
}
// `available` is the MINIMUM across every night of the stay, never a sum
// or an average. A room free on two nights of three is not bookable, and
// getting this wrong doesn't fail at search — it fails at payment, after
// the guest has entered card details.
// Returning perNight alongside the total is what lets the UI explain a
// price that moved, instead of a total the guest has to take on trust.How do you manage room availability and rates in real time?
- Room type inventory as a date-by-date grid: each cell represents rooms available for a check-in/check-out combination — stored in Redis for sub-10ms reads.
- Minimum length of stay (MinLOS), maximum stay, close-to-arrival (CTA), and closed-to-departure (CTD) restriction management.
- Rate plan hierarchy: bar → package → promotion → corporate → loyalty — with override rules and blackout dates.
- Dynamic pricing engine: adjust rates based on current occupancy, booking pace, competitor rates (via rate shopping API), and demand forecasts.
- Derived rates: rate plans calculated as a formula from BAR (e.g., 'Early Bird = BAR × 0.85') — update automatically when BAR changes.
- Search reads the date grid and returns the minimum availability across the stay. Nothing is held yet — search runs orders of magnitude more often than booking, so it has to stay cheap and cacheable.
- The guest picks a rate and the engine re-prices server-side rather than trusting the amount the client sends back. A rate that moved between search and checkout is a repricing prompt, never a silent charge.
- The hold decrements every night of the stay in one atomic operation. Partial holds are the overbooking bug: three nights written separately can succeed on two and fail on the third, leaving inventory quietly wrong until someone arrives to a room that was sold twice.
- Payment authorises against held inventory, and the hold carries a short TTL — long enough to finish a 3-D Secure challenge, short enough that abandoned checkouts return rooms on a date that is selling.
- Confirmation writes the reservation and emits an inventory-changed event. The channel manager pushes new availability to every OTA within seconds; a slow push here is exactly how the same room sells on two channels at once.
How do you connect a booking engine to OTAs and a channel manager?
For hotels selling through OTAs (Booking.com, Expedia, Airbnb), the channel manager distributes inventory and rates and receives reservations from each channel:
- OTA connection via OpenTravel Alliance (OTA) XML or HTNG APIs — each OTA has a slightly different implementation.
- Two-way sync: push rate/availability updates to OTAs within 30 seconds of change; receive new reservations and cancellations.
- GDS connectivity (Sabre, Amadeus, Galileo) via Switch or direct THISCO integration for corporate travel bookings.
- Rate parity enforcement: alert revenue managers when the same room is cheaper on an OTA than the direct booking engine.
- Commission tracking per channel for accurate profitability analysis.
How do you win more direct bookings instead of OTA bookings?
- Search to book in 3 steps maximum — every additional step costs 15–20% conversion.
- Real-time price comparison widget showing direct booking benefits vs OTA price.
- Urgency signals: 'Only 2 rooms left' (true, from live inventory) and 'Last booked 3 hours ago' (analytics-driven).
- Guest profile pre-fill for returning guests and loyalty members — reducing form friction.
- Multiple payment options: credit card, net banking, UPI, pay-at-hotel — localised by geography.
- Abandoned booking email sequence with optional promotional rate offer on second send.
Loyalty Programme Architecture
- Points ledger: double-entry accounting model — earned, redeemed, expired — with full transaction history.
- Tier management: Silver/Gold/Platinum with automatic tier evaluation at year-end and mid-year fast-track qualifications.
- Points earning rules engine: configurable earn rates by rate plan, season, property, and partnership.
- Redemption at booking: real-time points-to-currency conversion with minimum redemption thresholds.
- Partner earn/burn: airline miles, credit card points, car rental — requires bilateral API integrations.
- Direct Booking Conversion: +22%
- Revenue per Available Room: +15%
- OTA Commission Saved: 12-18%
- Loyalty Member Repeat Rate: +40%