Travel systems are integration problems wearing a booking interface.
The checkout is rarely the hard part. The hard part is that availability, pricing and cancellation rules live in somebody else’s system, and that system is slow, occasionally inconsistent, periodically down, and entirely outside your control. Your product is only as reliable as the least reliable supplier you depend on, which means the architecture has to assume failure rather than hope for uptime.
What we build
- Booking and reservation engines. Search, availability, hold and confirm, with the state machine that handles every way a booking can partially fail.
- Supplier and channel integration. Connecting to GDS, bed banks and direct supplier APIs, normalising inconsistent data models into one you can actually reason about.
- Dynamic pricing and packaging. Combining components into sellable packages with margin rules operators can adjust without a deployment.
- Post-booking servicing. Amendments, partial cancellations, refunds against non-uniform supplier policies, and the customer communications each of those triggers.
- Back-office and reporting. Commission reconciliation, supplier payment tracking and the margin analysis that tells you which products are actually profitable.
The problems worth naming early
Availability is a cache, and caches lie
Every travel system trades freshness against speed. Querying every supplier live on every search is too slow to sell; caching availability means occasionally selling something that is no longer there.
There is no configuration that makes this go away. The decision worth making explicitly, early, and with the commercial side of the business in the room, is what happens on the mismatch. Do you re-price and ask the customer to confirm? Substitute an equivalent? Absorb the difference and honour the booking?
Each is defensible. What is not defensible is discovering you have no answer at the moment it first happens, because by then a customer is already holding a confirmation email.
Bookings are distributed transactions with no coordinator
A package spanning three suppliers can have two confirm and the third fail. There is no rollback. The two confirmations are real, and somebody else’s inventory is now committed.
This needs compensating actions rather than transactions: an explicit cancel path for each supplier, a state machine that knows which components are confirmed, and a queue that surfaces anything that could not be resolved automatically to a human who can work it.
Booking state is therefore not a status column. It is a per-component record, and the overall booking state is derived from it.
Cancellation policy is where margin leaks
Every supplier has different windows, fees and refund mechanics. Some refund to source, some issue credit, some charge a flat fee, and some scale by proximity to travel.
Encoding these as data rather than as conditionals is the difference between onboarding a new supplier in a day and onboarding one in a sprint. It is also what makes it possible to quote a customer an accurate refund figure at the point they ask, rather than after a manual calculation that may be wrong.
Load is seasonal and campaign-driven
Travel demand follows the marketing calendar and the school calendar, not a smooth curve. Capacity should follow the same schedule, and load testing should use realistic peak profiles rather than uniform traffic. The shape matters as much as the volume, because a search spike and a booking spike stress entirely different parts of the system.
Currency and tax are not an afterthought
Cross-border travel means multiple currencies, exchange-rate exposure between quote and settlement, and tax rules that vary by the customer’s location, the supplier’s location and occasionally the route itself. Retrofitting multi-currency onto a system that assumed one is among the more painful changes in this sector.
Integration landscape
A typical platform touches GDS systems, bed banks, direct supplier APIs, payment providers, fraud screening and one or more channel managers.
The data models will not agree. Suppliers describe the same room, the same fare, the same cancellation window in incompatible ways, and some will return subtly different results for the same query depending on the time of day. The normalisation layer is where most of the real engineering effort goes, and treating it as glue code rather than as a core part of the system is a reliable way to end up with supplier-specific behaviour leaking into business logic.
Build it so a new supplier is an adapter, not a change to the booking engine.
What we would ask you first
Which suppliers you depend on and how you connect to each; what your current answer is when cached availability turns out to be wrong; whether you sell packages spanning multiple suppliers; how refunds are calculated today and by whom; and what your peak looks like relative to your average.
If the answer to the availability question is “it hasn’t come up yet”, it will.