There are dozens of ways to search for flights, and I tried them all. I carefully worked each of the three big Web travel sites at the same time, juggling multiple browser windows. Orbitz's Web site, Sabre Holdings' Travelocity and Expedia's site each offered different results. I tried alternative dates and airports. After more than an hour, I emerged from my office and called in my wife to confirm the final choice, bragging that the savings had been worth the time spent. But when I made that last mouse click to commit the transaction to my credit card, the reservation didn't go through.

My wife, who now calls me "Mr. Comparison Shopper," thinks I'm not playing with a full deck. But I suspect that the true problem was that I wasn't playing in real time.

The US airline reservations business is probably closer to real-time computing than any other industry except for financial services. But the database interactions among business partners required to provide real-time reservations data shows just how big a challenge real time presents.

Until the moment I tried to book my flight, I wasn't talking to the vendor's primary reservations database. I was accessing a secondary database designed for inquiries. Using such databases for flight searches makes a lot of sense, since the IT folks don't want thousands of queries bombarding the systems executing transactions that bring in real revenue.

Sabre Holdings' arrangement is typical. The global distribution system (GDS) vendor's high-speed, fault-tolerant HP NonStop servers consummate deals in a highly optimized database. At the same time, MySQL databases -- 45 of them residing on an Itanium-based Linux server farm -- serve up lowest-fare flight data in response to customer inquiries.

Unless fare price and seat-availability data presented to customers is updated in real time, users may not learn that a fare is unavailable until they try to complete the purchase. Sabre has addressed part of this issue by delivering continuous, live updates from the NonStop system to its MySQL database server farm.

A third-party data synchronization tool from San Francisco-based GoldenGate Software provides synchronous updates between databases. That's one reason why my corporate travel agent, Suzette, never has a problem confirming a fare using her direct connection into the Sabre system. She says employees like me call all the time saying they've gotten a better fare. "I say, 'That's great; see if you can complete it.' And they can't," she says.

The reason they can't may have something to do with the way reservation systems receive updates from individual airlines. For example, at Sabre, secondary databases contain only fares, rules and schedules. Prices are calculated in the primary NonStop database, and for real-time seat availability, the reservation system must query the individual airlines' mainframe databases.

Even the pricing information isn't in real time: Sabre and other GDS vendors receive updates five times each day from Airline Tariff Publishing, an industry cooperative. But providing real-time seat availability data is the biggest challenge.

A travel Web site can generate 100 searches per second that sift through 1,000 flights each. The volume of requests needed to verify seating for all of those would overwhelm the airlines' availability databases. To get around this problem, travel Web sites cache data and display hundreds of fares that the system predicts will be available.

The downside is that customers may receive options that don't exist -- either because the seating is unavailable or pricing data has changed -- and won't know it until they try to make the purchase. The alternative, which Sabre prefers, is to confirm availability in real time but show fewer options.

The airlines don't like Web sites caching availability information, but they can't respond to the potential volume of incoming requests, says Alan Walker, vice president at Sabre Labs. His company would like to bring a copy of each airline's master seat-inventory database in-house and receive real-time updates to it. In this way, it could compute availability and offer a larger number of accurate flight options to users. But in a round-the-clock system with such high transaction loads, Walker says the transition would be like "changing a tire at 100 miles per hour."

However, Walker doubts that these issues have anything to do with why I couldn't book my reservation. The other reason why Suzette never fails to book a ticket is because, unlike me, she can hold seats before they're purchased. So although it's possible that an inaccuracy in my fare search results was to blame, it's more likely that time spent comparison shopping did me in. Most likely, Walker says, "your seats were sold out from under you." And for some strange reason, my wife thinks that's funny.