I saw an interesting conversation on here about airline reservation systems and the services that connect them (like Sabre).

This is an almost identical analog to a problem I've been trying to figure out and I'm looking for the fundamental components required to build a service like Sabre (no this isn't a competing service but something that functions remarkably similar). So the elements of building a Sabre would be:

Access to the individual databases (through API I'm assuming) A portal through which a search is entered

The question(s):

Does it matter if the databases are compatible with one another (i.e. all on oracle etc.)? Just how big a project is this? It seems relatively straightforward to someone who's not a database programmer, but I totally know that's naiive. If my company were working to build a service like this (again, not for airline seats but the mechanism is very similar) what would first steps be?

To save everyone the snarky retorts, I understand that this is over my head personally, I'm trying to figure out what resources I'd need to get folks who could do it. No, I don't think I can teach myself, I know I need to hire crazy smart folks to do it. This is an attempt to understand the elements I need to put in place to get a start on this. I genuinely appreciate any help folks can give.

PS - two links that describe the essential functions relatively well:
Airline Reservation System
Computer Reservations System


5 Answers 5


You also have not described the scale or scope of what you want to do. Nor the required uptime.

If you dig into SABRE a bit more you will find its a very specialised system running direct on the hardware (pretty much no big-time OS involved - or more a case of the OS is the database system... TPF... its still around). Its also had a continuous up-time of something like 30 or 40 YEARS, and it services millions and millions of requests every day (if not every hour).

Something of that size and scale requires a very specialised piece of gear to do it - the right hardware and software. For things like this there is still a place for "old iron" as mainframes are known.

If you want to build something thats handling only a few hundreds of requests / minute them something much mroe mainstream may well do what you want.

  • where did you find that information? Sounds like good old Tandem NonStop/SQL I used to work with some 15 years ago.
    – jwenting
    Mar 21, 2011 at 11:43
  • 1
    I was looking (as you do) at old operating systems a couple of years ago - not long after making an airline reservation at a travel agent logged in to SABRE. Got to wondering a bit about it. Looked into it some more and discovered TPF. Check the wikipedia article about it. Found some more about it - parallelism, multi-machine, multi-disk... thousands and thousands of transactions/sec, the secret is specialised s/w direct running on the h/w, with very small disk records and very small mods made to them. No SQL in sight. Mar 21, 2011 at 21:28

Does it matter if the databases are compatible with one another (i.e. all on oracle etc.)?

As others have noted, the systems (yours as some kind of aggregate publisher 'broker service', your potential 'clients' who publish the 'available seats', and the potential 'customers' who price and 'reserve a seat') would not generally know anything about the underlying databases, and each would only know about some application service level interface of encoded function calls and respective return values.

Your system might use several differenet databases, each specially purposed (relational data, documents, or others depending on needs and acceptable tradeoffs), and each with potentially multiple copies of itself (redundancy/load balancing). Most vendors specialize in databases with one overall purpose or type, so it is possible you will have not only more than one type or kind of database for each particular purpose, but also as a result use more than one vendor or brand.

Just how big a project is this?

Compared to what? In what terms and to what extent?

Every project, big or small is essentially accomplished by breaking the work up into chunks, whether you prefer phases, iterations, increments, sprints, episodes, or some other lingo. Rome wasn't built in a day, and neither was SABRE or any other similarly purposed system. How much can you build in the first 'day' will depend on what resources you have supporting you, in terms of people (and their talent and dedication), dollars, infrastructure (physical assets for production and processes that effectively and efficiently manage that production), and at the very least, tentative clients (to name a few).

In order to get the supporting resources, you'll need both a business and a technical plan that lays out purpose and intended value, for the initial 'days' of the project, and in the later parts of the project, if it so endures. So essentially, you'll need to determine, in your specific case why and how, value will be present in 'day 1' of the system (what is going to be fundamentally the core features -- the system essence), and how many 'days' before your service is some how more valuable than what existing services or processes can offer (regardless of whether it shows greater value than an internal system of the client, or a competing service from another third party broker).

The technical complexity isn't trivial, but it is not a completely unexplored problem space, in general (when speaking of the elements of both a reservation system, and a reservation system using aggregation or brokerage features). The specific domain, and clients, without knowing more, is what makes this question impossible for anyone here to answer with any clarity. Perhaps the most obvious hurdle would be if the clients used obscure systems internally, and further have no method of externally accessing or publishing their information to your system, as that might put the burden on you to help them build that publishing mechanism, and consequently, giving the the respective reservations back to the client, if they have to this point no means of processing 3rd party reservations.

The second most obvious technical hurdle would be client specific reservation rules. Each client may use unique rules when processing a reservation request from a customer. You probably won't be able to get clients to harmonize their rules in order for all clients to use the same rules, so your system may have to, in a sense, duplicate and honor those rules in code, and potentially make them appear harmonious to users so is not to induce a sense of favoritism for one client over another on your part. Unintended or otherwise.

The hardest part will change as time goes on. Initially, getting clients on board (willing and financially supportive), and integrated (fully able to use all advertised features of your service from a client perspective) will be the hardest parts.

As your service become more popular with customers and clients, reaching a certain system maturity, you will experience infrastructure challeneges and to some degree further business challenges: the system will need to handle more users, more users at precisely the same time, more users with specific needs (cultural issues like language/translation, physical issues such as audio or visually impaired), public exposure and political/legal issues, support issues reported by both users and possibly clients for pecularities (technically, this might be called 'edge cases' that you previously hadn't considered or valued high enough to fully explore and implement). Ad nausium.

On top of that, in essence, a 3rd party reservation system is creating a market place, and any market place will face competing interests. Some things your clients want will be unpopular with customers, and vice versa. Some things a particular client wants will break usability or feasability for another client.

It seems relatively straightforward to someone who's not a database programmer, but I totally know that's naiive. If my company were working to build a service like this (again, not for airline seats but the mechanism is very similar) what would first steps be?

The first step in creating a brokering system, is to ensure there is adequate interest from potential clients to move forward. If no one is interested in playing, it may not be worth pursuing. For the airlines, I am fairly certain there are strict contracts or service agreements that lock them in relationships between brokers and clients, so penatrating a market like that would mean potentially sitting on the sidelines until the contract is up for renewal, or worse.

  • This is fantastic guidance. I appreciate so much the time and thoughtfulness you've put into this! I've already thought through most of the business points you make, but some of the transactional issues were definitely lightbulbs for me. Again, I'm pretty tech savvy but this is way over my head in skill and experience so I'm trying to scratch out enough information to figure out who to hire and what elements to plan for. It's somewhat of a chicken and egg question: biz plan and resources (funding in particular) first or knowledge and skill (which aren't free)? Thank you for your help!
    – Robert1er
    Mar 26, 2011 at 2:43
  • It is a bit of a conundrum, but at the end of the day, whether the venture is of a commercial interest, academic, or a charitable one, the business has to be first. Perhaps, at some point, there is a need to demonstrate something that would be technical, but resourcing that demo still goes back to some phase of the business plan.
    – JustinC
    Mar 26, 2011 at 2:55

The reason that nobody has answered is that the answer depends to a great deal on specifics that you have not given us. Such as what the exact problem space is and whether there is anything resembling an industry standard to theoretically make life easier. And even then the answer will depend on what that standard looks like, and how well people comply with it. Which is something that you, as a non-coder, are not in a good position to figure out. And is something that will take some research from the person who will try to be solving it even to figure out the true scope of the problem.

Therefore the best advice that I can give you is to follow the nice flowchart at Codified Startup Advice. It appears that you are at the Have a hacker founder? step and are answering No, and would like to answer Don't need one? following that.

  • no, the reason seems to be he's mentioned he wants to reverse engineer someone else's product that he has no rights to, which is at best unethical and at worst illegal. Had he just asked about the general architecture and construction of such systems he'd probably have got more help :)
    – jwenting
    Mar 21, 2011 at 7:26
  • @jwenting: He didn't say that. He said something that is an almost identical analog. I can think of lots of things that can be thought of as "almost identical analogs" that would be quite different. For example a tool to plan a trip that potentially uses multiple modes of transport.
    – btilly
    Mar 21, 2011 at 7:40
  • the very term "reverse engineering" puts off a lot of people.
    – jwenting
    Mar 21, 2011 at 11:37
  • Jwenting: I'm sorry I wasn't more clear. The product I am interested in does not exist, and is in an entirely different space than sabre, but (as I said) is an analog to sabre. It is in no way a competitor to Sabre or anyone else for that matter, but functions similarly.
    – Robert1er
    Mar 22, 2011 at 4:04
  1. does it matter if databases are the same: no, as you'd never talk directly to the databases. You're talking to software that talks to the databases using an agreed upon language.
  2. just how big is it: that is impossible to tell given the data you provided. At the very least it's non-trivial, at the worst it's a massive undertaking requiring many millions of up-front investment to pull off.
  3. how to get started: hire/contract a business analyst and an architect with in-depth knowledge of your industry to hammer out the requirements and an initial design specification. That should give some indication of the expected cost in time, finance, and other resources to get it implemented.

I'm not 100% sure of how it works in the airline reservations business, but I do know many airlines offer their seats through a common 3rd party. Reservation services connect to that party and can search for available seats based on criteria such as departure/arrival (obviously), date/time of travel (with margins), preferred airline, etc. Some or most also offer access to their own systems. Never is access to the database granted directly, instead you talk (through web services, EDI, or whatever protocol) to an application that sits in front of the database and handles things like security, validation, payment processing, etc. etc.. These services can differ wildly, which is one reason a common broker was put in place.

  • This is helpful. My impression was that Sabre is the common broker, but maybe I'm wrong here. That's the piece I'm trying to figure out--the common broker that (I assume) queries the various databases with a particular set of criteria.
    – Robert1er
    Mar 22, 2011 at 4:12
  • Without spelling the whole thing out, the "common broker" as you've mentioned it is what I'm trying to figure out. Are there particular types of architects that would work on this type of a system? I assume it requires an understanding of DB programming in addition to some sort of front-end interface?
    – Robert1er
    Mar 22, 2011 at 4:13
  • you will need a database in your own system, no doubt about that. But that's to store your own data (and whatever you want to cache that you get from your suppliers), you will NOT talk directly to their databases. Systems like this don't require one architect, they require an entire team.
    – jwenting
    Mar 22, 2011 at 7:37
  • hardware, software, database, network, interaction with 3rd parties, it all has to work and come together.
    – jwenting
    Mar 22, 2011 at 7:38
  • You make a good point about requiring a team. I don't doubt that this is a large endeavor, though in my head I think I had oversimplified the resources it would take. I plan on pursuing it still, but clearly will need to figure out how to select such a team. If this were a field I already worked in, I suspect it would be easier to identify the resources, but I suppose I'll need to find some sort of project manager with experience in this area.
    – Robert1er
    Mar 25, 2011 at 19:47

Sounds like the first person you want to hire is a software architect. I realize you're being intentionally vague, but the details you're leaving out make a big difference in how we can answer. Some things to consider:

  • Whether one company controls everything or a loose consortium of companies. If the former, you can usually start with some basics and add details as you need them. For the latter, it usually means months of meetings hammering out detailed specifications that meet everyone's needs for the foreseeable future, before you even hire the people that will be creating the implementation.

  • How geographically distributed your users are. If you're in one building, one campus, one city, one country, or worldwide can make a big difference in your architecture and approach. Does your app have the same scale as Sabre, or just the same basic functionality?

  • Whether you need to support different operating systems and different versions of those operating systems, and different databases and database versions, or you can standardize on one. Wider support is definitely technically doable and sometimes an absolute necessity for business reasons, but also takes more work to develop and support, so it makes sense to avoid it if possible.

  • What your availability requirements are. 24/7 or banker's hours.

  • Security requirements. Is your system intended for only a group of trusted users on trusted systems, or do you want to enable any customer to book a reservation themselves?

The resources required based on what you've given us so far could mean anything from a trip to Best Buy and one guy to write the software, up to a multi-million dollar data center.

  • Great points all. I also recognize that vagueness makes it hard to answer the question comprehensively (though you did an excellent job of pointing out some key issues to consider). It seems like many of your points relate to scale (userbase, geography, flexibility etc.) and in most ways this will be very similar scale to a service like Sabre with the exceptions being that this will have a relatively small userbase (probably several hundred people worldwide) and on trusted systems. The software architect comment helps. That's the type of advice I need most-what resources to start with. Thanks!
    – Robert1er
    Mar 26, 2011 at 2:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.