Anatomy of a Booking

At ten past nine on a Friday evening, a family of four in a hotel room in Munich chooses a day tour to Neuschwanstein for the following morning. One of them opens a distributor’s app, scrolls the results, taps the tour with the best reviews, enters names and a card number, and receives a voucher in around twenty seconds. From the outside, this looks like a small act of consumer commerce, not meaningfully different from ordering a taxi.

The purpose of this essay is to describe what actually happens during those twenty seconds, and during the hours and days on either side of them. The previous essays in this series have traced the industry’s structural position (digitisation lag, fragmentation, shadow infrastructure) at a general level. The picture is still abstract. Before the arc can turn to what an alternative industry stack might look like, the existing stack needs to be legible. One booking, traced from consumer tap to operator manifest, is the cheapest way to make it legible.

The boundaries a booking crosses

A consumer booking in this industry typically crosses six boundaries between systems that belong to at least three different organisations.

The first is between the customer’s device and the distributor they are buying from. The second is between the distributor’s customer-facing layer and its back-end, where cart and pricing logic live. The third is between the distributor’s back-end and whatever it uses to reach supply (a direct operator connection, a neutral specification such as OCTO, a channel manager, or a large marketplace’s proprietary supplier interface). The fourth is between that connectivity layer and the supplier-side reservation system. The fifth is between the reservation system and the operator’s own database and daily manifest. The sixth is between the operator’s system and the voucher that eventually reaches the customer.

Each boundary has its own authentication, its own data model, and its own ways of failing. A successful booking is the concurrent success of all of them. A failed booking is the failure of any one.

The sequence

Underneath the family’s four screens (product, calendar, checkout, confirmation), the conversation between systems proceeds in roughly the following order.

Long before the family opens the app, the distributor already has a product catalogue for this supplier in its own systems. In a fully automated topology, that catalogue is pulled from the supplier’s reservation system on a continuous background cadence. In practice, for a substantial share of suppliers in this industry, the catalogue is maintained by the supplier directly inside a distributor extranet, a web portal where prices, photographs and descriptions are entered and updated by hand.^¹ The consumer cannot tell the difference between the two routes; the operating cost and the staleness risk behind each are not the same. For the rest of the sequence, it does not matter which route the content took, only that the distributor now has something to show.

When the family chooses tomorrow’s early-morning departure, the distributor asks the supplier’s system whether that exact slot is still open, with that exact mix of passengers, at the price the customer is seeing. This is the first synchronous conversation in the sequence, and it happens inside the twenty-second envelope the customer is willing to tolerate. Assuming the answer is yes, the distributor places the seats on hold. The hold is a temporary reservation that protects those seats while the customer enters card details. Holds carry a time limit, typically measured in minutes.^² If the customer walks away, the seats return to inventory.

The card authorisation happens on a separate conversation with the payment processor. This is a different organisation, a different data model, a different set of failure modes. It is on the critical path of the booking, but not on the booking connectivity path.

Once payment is authorised, the hold is converted into a firm booking. The supplier-side system returns a confirmation identifier and a voucher or scan-ready token. That voucher propagates back through the chain to the customer, and independently into the operator’s daily manifest. The operator is now expecting the family at the Munich pick-up point the following morning, and the family has a record they can present on arrival. Between ten and twenty separate conversations between systems, in most topologies, across the six boundaries above (and sometimes more, when the supplier itself calls further upstream), all inside the time it takes a consumer to type a card number.^³ The booking, as the consumer experiences it, is a polite fiction stitched together in real time across systems that do not share an owner.

The translation burden

The same booking is described differently at every boundary. At the first boundary, it is four names and a card. At the distributor’s back-end, it is a cart line item, a pricing plan, and four roster entries. At the connectivity layer, it is reshaped into whatever data model the supplier-side system expects: units, age bands, ticket categories, unit types. The supplier’s reservation system may map those categories again to whatever the operator has configured locally, which may be “adult,” “student,” “family,” with its own pricing rules attached. On the way back, the voucher carries a pax count in a format the distributor can display.

Each translation is a place where data can drift, and each is a place where a version change somewhere else in the chain can break something here. When the operator introduces a new pricing category, the mapping on the reservation system changes, the connectivity layer’s translation changes, and the distributor’s catalogue must pick up the change. Each of those changes is an engineering ticket somewhere.

In the aggregate, the translation layer is where the permanent cost lives. The first integration build is a one-off expense. The translation layer is paid every time any one of the data models in the chain changes, forever. That is why Essay 3 argued for integration as rent rather than capex. This is where the rent is paid.

The speed constraint

A checkout experience that takes longer than a few seconds loses customers. The thresholds are well established: about one second before a user’s flow of thought is interrupted, ten seconds before attention is lost altogether.^⁴ All of the synchronous conversations above have to complete within that window, or the distributor has to build fallback behaviour that hides the latency.

Most of the industry’s published guidance to partner developers accommodates upstream response variance measured in tens of seconds on individual calls; in practice the budget at the customer’s end is much tighter than that. The slower the supplier-side system, the faster everything else in the chain has to be. If a channel manager sits between the distributor and the supplier, each call traverses an additional hop on the way out and another on the way back, consuming more of the same budget. If the supplier must itself call further upstream, for example to a partner for a combined-ticket product, the depth of the chain increases again.

The operational reality is that the latency the customer perceives is the slowest boundary in a chain, compounded by the hops between them. The faster boundaries are doing work no customer will ever attribute to them. The slowest boundary is absorbing reputational cost for the whole stack.

Where the interesting weight lives

The happy path is not where the weight of the system sits. The weight sits in the failure modes.

Two customers, in different cities, attempt to book the same last seat in the same second. Hold semantics exist to prevent this, but holds themselves temporarily consume inventory on bookings that may never confirm, which creates an inventory-accuracy problem of its own. The trade-off, between accurate inventory and serving every customer who tries to book, is the everyday face of Brewer’s consistency-versus-availability problem in distributed systems.^⁵

The family enters card details, gets distracted, closes the app. Fifteen minutes later, the hold expires and the seats return to inventory. If the payment processor has already authorised the card, the distributor is now holding an authorisation for a booking that no longer exists. Reconciling authorisations to bookings is a full-time job at any distributor at scale.

The price the family saw at 21:09:30 came from the availability check. Between then and booking confirmation, the supplier republished prices for tomorrow. The distributor must decide whether to honour the original price, reprompt the customer, or absorb the difference. Each of those choices has an operational cost and a customer-experience cost.

The booking confirms on the supplier side, but the voucher email does not reach the customer because a mail provider marks it as spam. The operator has the family on tomorrow’s manifest; the family has no record. The operator learns of the booking when the family does not appear at the pick-up point. Recovering the situation requires three organisations to reconstruct state from logs.

The supplier’s system is unreachable for six minutes. During those six minutes, every availability check for that supplier fails. The distributor either caches stale availability, and risks overbooking, or returns “no availability” to every customer who searches, and loses bookings the operator would gladly have taken. Either way, the cost is real and distributed across organisations that never see each other’s logs.

Every working distributor and every working supplier-side system maintains internal tooling to detect and respond to these situations.^⁶ None of that tooling shows up on a balance sheet as infrastructure. It is, again, the shadow infrastructure of Essay 3, paid for engineer by engineer, ticket by ticket.

Why vertical integration matters structurally

When a distributor and a reservation system sit inside the same corporate perimeter, the third, fourth and fifth boundaries collapse. They stop being cross-organisation interfaces, and become internal function calls inside a single company, against a single data model controlled by a single product team. The consumer-facing experience is indistinguishable from the non-integrated version. The underlying operation is materially cheaper to run, and the failure modes are fewer and easier to diagnose.

This is the structural advantage the category’s largest online travel agents have acquired by buying reservation-system vendors in the layer beneath them. It is rational on their individual economics. It also compounds asymmetry across the rest of the industry, because the distributors that have not vertically integrated, and the suppliers that distribute through them, continue to pay the cross-boundary cost on every booking. Essay 3’s argument about a neutral specification lands here concretely: the participants with the most leverage to move the industry toward a neutral layer are precisely the participants who have already solved the boundary problem inside their own walls.

What the picture suggests

Accept the topology as described. Six boundaries, a dozen conversations, a translation layer at every interface, a continuously operating failure-response stack that nobody accounts for as infrastructure. The natural question is not how to make any one boundary faster. It is whether the topology itself is inevitable, and whether a neutral layer could emerge that collapsed some of these boundaries for participants who cannot buy their way into vertical integration.

The next essay takes up the analogy the industry reaches for most often when trying to think about exactly that possibility. It does the Amadeus-and-Sabre comparison honestly, and shows how much of what made a neutral layer possible in aviation is absent in experiences, and what that absence actually implies.

The system works. That it works at all is the accomplishment. That it works this way, for everyone except the vertically integrated, is the problem.