The engineering problem

The gap between a booking system that works and one that converts is not a design problem. It is an engineering problem. Availability queries that take three seconds cause drop-off before the results page renders. Payment flows that fail on mobile at the confirmation step waste everything that came before. Booking systems that hold inventory for too long create ghost availability; systems that hold it too briefly create failed reservations at the worst possible moment.

A production-grade booking engine is a composition of interdependent components - each with its own latency budget, failure mode, and business impact. The discipline is in understanding those dependencies and designing for the case where two suppliers return conflicting availability states, or a PSP introduces a 400ms spike, or peak demand hits a pricing rule that was never stress-tested.

Gradion has built booking systems for operationally demanding travel platforms across accommodation, experiences, rental mobility, and niche verticals including faith-based travel. The patterns and engineering decisions from those engagements inform how we approach every booking engine we build.

What we build

IBE architecture

An Internet Booking Engine is not a checkout page. It is the full system from intent to confirmed reservation: availability query, results presentation, option selection, ancillary add-ons, guest or passenger data collection, payment, confirmation, and the supplier notification that closes the loop. Each stage has its own failure surface. Gradion designs IBE architecture as an end-to-end system, with explicit decisions at each boundary: where inventory state is read from, when a hold is created, how payment failure is recovered, and what happens when supplier confirmation is delayed. IBE architecture for different travel verticals - hotels, rental vehicles, tours and activities, flights - shares the same structural pattern but differs significantly in data models, supplier connectivity, and the business rules that govern pricing and cancellation.

Search and filtering

Parameterised availability queries across distributed inventory sources. Faceted filtering by location, date range, capacity, price band, and amenity or feature set. Relevance scoring that balances match quality against supplier margin and conversion data. Sub-500ms latency targets are achievable with the right combination of index design, query planning, and edge caching, but require deliberate architecture from the start rather than retrofitted optimisation later.

Real-time availability

Inventory reservation patterns carry material business consequences. Optimistic locking allows higher throughput but risks oversell. Confirmed holds guarantee inventory but reduce availability for concurrent users. Soft holds create conversion windows but require expiry logic and cleanup. The right pattern depends on supplier type, booking value, and demand concentration. HomeToGo’s real-time availability across 100+ partner APIs - each with its own response characteristics, data model, and reliability profile - required a normalisation and caching layer capable of handling continuous data streams at volume while maintaining accuracy that travellers and partners both trust.

Pricing engine

Dynamic pricing rules by date, market, channel, and inventory level. Promotional pricing, package bundling, and add-on management. Revenue management integration for operators who model demand curves. Tax and fee calculation by jurisdiction. The pricing layer must be auditable and testable - incorrect pricing at scale is a legal and reputational exposure, not only a revenue one.

Booking flow design

Friction reduction through progressive disclosure: collect only what is needed at each step, defer optional fields, pre-fill from user account data where available. Mobile-first form design with appropriate keyboard types, tap target sizing, and autofill compatibility. Each step in the flow should be independently A/B testable, which requires the flow to be modular from the architecture level rather than a single server-rendered monolith.

Payment integration

PSP connectivity across Stripe, Adyen, and Braintree - with payment method localisation by market. SCA handling under PSD2 without unnecessary friction for low-risk transactions. Partial payment and deposit flows for high-value bookings. Cancellation and refund processing with rule-based eligibility. 3D Secure flows that degrade gracefully on older devices. Payment failure recovery paths that do not lose the session or the booking intent.

Supplier and inventory connectivity

OTA channel manager integrations: Beds24, Lodgify, Guesty, direct XML feeds. GDS connectivity for transport inventory: Amadeus, Sabre, Travelport. Custom API integration for direct supplier relationships. Connectivity layer design that abstracts supplier-specific quirks - rate limits, authentication models, data schemas, error handling - so that booking flow logic is not polluted by integration-specific conditionals.

Price monitoring and automated rebooking

For platforms where the core value proposition is cost reduction on existing bookings, the booking engine extends beyond the initial reservation into a continuous monitoring loop. Gradion built the booking system for a travel startup whose product was monitoring hotel prices after a booking was confirmed and automatically rebooking at a lower rate when found. This required reliable tracking of the original booking reference, a rules engine for rebooking thresholds, and a flow that executed the new booking and cancelled the old one without the customer losing their room. The cancellation and rebooking logic had to account for rate plan terms, blackout periods, and the window between new booking confirmation and old booking cancellation - a narrow sequence where both reservations held simultaneously. The system worked at scale across multiple hotel suppliers, each with different cancellation APIs and confirmation response times.

Faith-based and specialist travel IBE

Specialist travel platforms carry filtering and content requirements that general-purpose booking engines do not address. Gradion built the booking engine for one of the first Muslim-focused travel platforms - an IBE where travellers could search for and book halal-certified hotels specifically. This required supplier content enrichment beyond standard hotel attributes: halal certification status, prayer facilities, alcohol policy, proximity to mosques, and direction of Qibla. The filtering layer had to surface properties that met these criteria from supplier feeds that did not natively carry them, which meant building a content layer that classified and tagged properties using a combination of supplier data, third-party datasets, and manual verification workflows. The booking flow itself was standard IBE architecture; the differentiation was entirely in the inventory preparation and filtering layer upstream.

Confirmation and communication

Booking confirmation emails, calendar sync via iCal, pre-arrival communication sequences, and post-stay review requests. Operational notification triggers for supplier or host: new booking, modification, cancellation, check-in imminent. Communication architecture that supports multi-language and multi-timezone delivery without coupling to the booking transaction itself.

Performance architecture

CDN strategy for static assets in the booking funnel. Server-side rendering for booking funnel entry pages, combining SEO benefit with first-contentful-paint performance. Edge caching for availability responses with TTLs calibrated to supplier update frequency. Load testing under realistic concurrent-user scenarios before launch, not after.

Proof in production

HomeToGo: 15 million+ listings, 100+ partner API integrations, 50+ production deployments per day, 99.99% uptime across 25 markets. NFQ (represented by Gradion) provided up to 150 engineers across multiple offices during the platform’s growth phase from founding through EUR 1 billion IPO.

roadsurfer: full booking platform rebuilt in 20 days. The rebuilt system - multilingual, multi-currency, with a modern back-office and CI/CD pipeline - supported a doubling of bookings and revenue and a 40% expansion in fleet size within a year of launch.

GoVibe: experiences booking platform built during COVID for domestic travel. The MVP launched in three months. In the rebound year, bookings grew 290%.

CTA

Describe the booking flow and the conversion or availability challenge. We will scope the architecture.