The problem
You’re booking your next holiday and while checking prices you key in the search for one passenger. When it comes time to make the actual booking, you select the required four passengers for your family, but suddenly the price per ticket rises from $250 to $400!
Why it happens
Airline booking systems (aka Global Distribution Systems / GDS) cannot split a single booking across "buckets" (fare classes). If there are two seats left at $250 and you need four, the system doesn’t give you two at $250 and two at $400 (which would be common sense). It bumps the entire group into the higher bucket, which is $400 per ticket.
The UI rarely explains this. It just silently adjusts the price for everyone, hoping you’ll just put it down to tickets selling out quickly right n…
The problem
You’re booking your next holiday and while checking prices you key in the search for one passenger. When it comes time to make the actual booking, you select the required four passengers for your family, but suddenly the price per ticket rises from $250 to $400!
Why it happens
Airline booking systems (aka Global Distribution Systems / GDS) cannot split a single booking across "buckets" (fare classes). If there are two seats left at $250 and you need four, the system doesn’t give you two at $250 and two at $400 (which would be common sense). It bumps the entire group into the higher bucket, which is $400 per ticket.
The UI rarely explains this. It just silently adjusts the price for everyone, hoping you’ll just put it down to tickets selling out quickly right now, or some other cause like dynamic pricing.
The root cause
Its caused by a 50-year-old legacy backend design. Airlines use buckets, denoted by single letters (Y, B, M, K, L, etc.). The GDS treat a booking as an atomic unit, so if you search for a party of four, the system only tries to find four seats within the same fare bucket.
Example - when a booking engine sends a "Sell Request" to the backend, it sends a single message:
SELL 4 SEATS IN CLASS Q
The legacy backend that receives the request is pretty basic - it doesn’t have the ability to apply the logic, "I only have 2 left in Q, so I’ll give you those and put the remaining 2 in M." It instead just looks at the remaining seats in Class Q.
If Available < Requested, it returns:
ERROR CLASS UNAVAILABLE
The booking middleware is programmed to catch that error and retry the request for the next bucket letter, until it finds a bucket which has the required number of total seats available, which means the request succeeds.
How to minimise your group fare
Given this limitation, how can you ensure you always pay the minimum possible? Its a pretty simple method - the one-by-one search technique. Search for one passenger first. Keep incrementing the number of passengers you search for, until the price per ticket bumps up. Then you know how many seats remain in the cheapest bucket. So exhaust that cheapest bucket before going ahead with the the rest of your booking.
Why don’t Airlines fix it?
So why haven’t they fixed this core issue - that’s in fact a "group booking tax"? The answer is likely technical debt on a global scale combined with the lack of a financial incentive. To change it, you’d have to synchronize updates across tens of thousands of travel agencies, hundreds of airlines, and third-party aggregators.
Rather than fixing the root issue, the industry just builds layers of shiny new wrapper APIs on top of the same legacy core. Another name for this is pig’s lipstick code.