The United Airlines reservation system designed by Evelyn Berezin

Sistema de reservas de United Airlines

Historical correction: an earlier version of this article identified the computerized United Airlines reservation system designed by Evelyn Berezin as UNISEL. Original Teleregister documentation shows that UNISEL was already operating in 1955, before Berezin joined the company in 1957. The later system associated with Berezin was a different project, begun around 1958 and identified as Instamatic by the National Inventors Hall of Fame.

The distinction matters because it shows how computerized airline reservations actually evolved. Teleregister did not jump from manual reservations to a large central computer in one step; it spent years developing successive generations of availability, inventory, and communications systems.

Teleregister was already building reservation systems

A 1956 Teleregister brochure provides an unusually useful snapshot of this period. It describes an availability installation for American Airlines dating back to 1946 and a magnetic-drum-based Magnetronic Reservisor placed into service in 1952.

The same brochure has a section on United Airlines and identifies UNISEL as a system developed for the airline. Its first availability phase had entered service in 1955 in New York, Chicago, Los Angeles, and San Francisco.

Excerpt from Teleregister’s 1956 brochure documenting United Airlines UNISEL, an earlier system that predates Evelyn Berezin’s later project.

UNISEL used availability panels and remote keysets so reservation agents could check seat inventory. Teleregister also described a planned evolution toward a more centralized design using magnetic-drum storage.

Berezin’s project began around 1958

Evelyn Berezin joined Teleregister Corporation in 1957 as head of logic design. In her Computer History Museum oral history, she said design of the later United Airlines system began around 1958.

The National Inventors Hall of Fame calls the system Instamatic and says it was operational by 1961. The Computer History Museum describes delivery around 1962. These dates can reflect different installation and rollout stages, so we use 1961–1962 as the deployment period.

Berezin described the project as more than a simple availability display. It had to maintain data about tickets and seats on each flight while responding in real time to terminals around the country.

The central computer was in Denver

According to Berezin’s oral history, the central system was located in Denver and served terminals in about 60 U.S. cities.

The key problem was communication. Long-distance data links were slow and far less reliable than modern networks, so every terminal message had to be transmitted, interpreted, processed, and stored quickly enough to keep the reservation workflow usable.

Three independent linked processors

The Computer History Museum summarizes the central design as three independent linked processors. Calling this a modern “cluster” or describing its components as load balancers would be anachronistic.

The architectural purpose, however, is familiar: the reservation service could not depend on a single machine whose failure would stop the entire operation.

High availability before the modern terminology

Berezin said the service had to operate 24 hours a day, seven days a week, and that a central-machine outage lasting more than seconds was unacceptable.

The design therefore emphasized independent components and recovery. The goal was not to make individual hardware incapable of failing, but to keep a localized failure from becoming a system-wide outage.

Approximately one-second response time

The Computer History Museum reports a response time of roughly one second. That performance is particularly impressive in the context of late-1950s and early-1960s computing.

There were no enterprise IP networks, distributed databases, solid-state drives, or automated data centers. The computers themselves were much slower, and long-distance communications were a major engineering constraint.

Communications were part of the system architecture

One of the most useful insights in Berezin’s oral history is that she treats communications and computation as a single design problem. Integrating remote terminals meant calculating how quickly a message could travel, be analyzed, and update the corresponding reservation data.

The communications infrastructure was purpose-built for the application. Reliability depended on the behavior of both processors and links, not on the central computer alone.

Eleven years without a central-system failure

The Computer History Museum reports no central-system failures during eleven years of operation. This should not be misread as a claim that every terminal, line, or physical component worked continuously for eleven years.

The important result is that component-level failures did not become a complete central-service outage — exactly the distinction high-availability architecture is intended to achieve.

Was it the first computerized airline reservation system?

It is better not to make that absolute claim. Teleregister had already deployed electronic airline availability and inventory systems, and other companies were developing computerized reservation technology as well.

Berezin’s system is important for a different reason: it was one of the largest computerized passenger reservation systems of its era, combining real-time processing, nationwide communications, and fault tolerance with exceptional reliability.

What modern analogies can and cannot tell us

Terms such as replication, sharding, load balancing, and microservices can help modern readers understand certain goals, but they were not the historical names or exact mechanisms used in this installation.

What the sources do support is a system with:

Independent linked central processors.
A design intended to preserve service when components failed.
Geographically distributed remote terminals.
Purpose-built data communications.
Real-time processing with roughly one-second response.
Continuous 24/7 operation for a critical business application.

A systems-engineering lesson that still applies

More than six decades later, the central lesson is still recognizable: design systems with the expectation that components will fail.

Today we use replicated servers, distributed databases, redundant networks, observability, and automatic recovery. Berezin’s team had none of those modern tools, but they were solving the same fundamental problem: keeping a local failure from becoming a total service interruption.

Berezin after Teleregister

Berezin later founded Redactron in 1969 and led development of the Data Secretary, one of the early electronic word-processing systems intended for business offices.