Platform module
Booking engine
One flow from search to voucher, for every product type.
What makes a travel booking engine correct?
Correctness is ordering. TravelCore re-checks the rate, journals the intent, then calls the supplier — so a crash mid-flight leaves a record rather than a mystery. Every state-changing call requires an idempotency key fingerprinted against its body. A supplier timeout becomes an unknown outcome awaiting reconciliation, never a silent failure and never an assumed success.
The booking engine owns the sequence that every travel product shares: search, select, re-validate, collect traveller data, take payment, confirm with the supplier, and issue a document. Product types differ in their details, so the engine models the shared spine once and lets each product plug its own availability, pax model and cancellation grammar into it.
The step most systems get wrong is re-validation. Suppliers reprice between search and booking, and a system that trusts the searched price either eats the difference or fails after the card is charged. TravelCore re-checks the rate against the supplier immediately before payment and reports whether the price held, so the decision to absorb, pass on or abandon is yours and is made before money moves.
Confirmation is treated as a distributed transaction, not a function call. Every booking attempt carries an idempotency key, is journalled before the supplier is contacted, and is reconciled afterwards. A timeout from a supplier is an unknown outcome, not a failure, and the engine resolves it by querying rather than by assuming.
This correctness core is real code rather than a description, and it runs on this page against a supplier you can break on purpose. It is the same TypeScript the test suite imports, covered by 23 tests. The one worth trying: the timeout that created the reservation anyway — press book three times and the supplier is still called once.
The hard part
The unknown-outcome problem
When a supplier times out on a booking call, the reservation may or may not exist. Systems that treat a timeout as a failure create duplicate bookings; systems that treat it as a success create phantom ones. The engine journals intent before the call, then reconciles by querying the supplier with the client reference until the true state is known.
Capabilities
- Search, select, re-validate, pay, confirm, voucher
- Hotels, flights, transfers, activities, cars and packages on one spine
- Idempotent booking creation with replay-safe keys
- Pre-payment rate re-validation with an explicit price-held flag
- Structured cancellation policies with absolute deadlines
- Timeout reconciliation: unknown outcomes are queried, never guessed
- Promo codes, coupons, taxes and service fees applied by rule
- Voucher and invoice generated from the stored booking record
Run it yourself
Make the supplier misbehave
The booking engine below is the same code the test suite imports, running against a supplier you can break on purpose. The interesting one is the timeout that created the reservation anyway: press book twice and watch the supplier still get called once.
Supplier behaviour
Choose how the supplier misbehaves
Testing a booking path against a supplier that always succeeds proves nothing. These are the failure modes that happen in production and are almost never exercised before they do.
Attempts made
0
Supplier calls
0
Reservations held
0
Unresolved in journal
0
Related
The rest of the core
Pricing and markup engine
Net rate to final price, by rule, versioned and auditable.
Hotel mapping and normalisation
The same property from many suppliers, resolved to one object.
Supplier control center
Onboarding, credentials, mapping runs and honest health data.