The inventory changed while you were checking out

Usually a combination: parallel fan-out with per-supplier timeouts, returning partial results instead of waiting for the slowest upstream, caching availability against a freshness policy you have actually decided on, and pre-warming the routes and dates people search most. Adding hardware is the least effective item on that list and the one most often tried first.

Treat the booking as a durable workflow rather than a request. Each step is idempotent and recorded, failures trigger a defined compensating action, and a reconciliation process compares your records against supplier records to catch the ones that slipped through anyway. Some always do, the point is finding them before the traveller does.

Almost certainly, including the ones with thin documentation and XML from another era. Certification timelines and sandbox access are usually the schedule risk rather than the code itself, so we start those in week one rather than discovering them in month three.

You decide the policy and we implement it consistently: reprice at checkout, honour a held quote for a fixed window, or absorb small deltas within a threshold. What generates complaints is rarely the repricing itself, it is doing it inconsistently, or telling the customer too late in the flow.

Trip discovery in natural language over your own inventory, and post-booking service, changes, cancellations, status, where the agent can read the booking and the fare rules. Anything involving a fee waiver, a stranded passenger or a supplier exception should reach a human, and we build that handoff deliberately.