Sistemas de reservas aéreas: por que ainda estão em mainframes

Ao reservar um voo em um smartphone em 2026, sua solicitação passa por múltiplas camadas de tecnologia moderna — um aplicativo móvel, um serviço web, um processador de pagamentos — antes de chegar ao sistema que de fato garante sua reserva. Esse sistema, na maioria dos casos, é um software com raízes na década de 1960, executado em uma infraestrutura que a indústria de viagens tenta substituir há décadas, sem sucesso. Sabre, Amadeus e Travelport, juntas, gerenciam praticamente todas as reservas aéreas do planeta. Elas processam bilhões de transações anualmente, abrangendo centenas de companhias aéreas, milhares de agências de viagens e um inventário em tempo real com milhões de combinações de assentos. A mais antiga delas remonta a um mainframe da IBM de 1964, que reduziu o tempo de reserva de 90 minutos para meros segundos e mudou a aviação comercial para sempre.

A história de por que esses sistemas permanecem onde estão não é uma história de inércia organizacional ou conservadorismo de engenharia. É uma história sobre o que acontece quando o software se torna tão profundamente integrado a um processo operacional crítico que o custo e o risco de substituí-lo não podem ser justificados em nenhum cronograma realista, e como a indústria respondeu modernizando em torno do núcleo, em vez de tentar substituí-lo. Para qualquer pessoa que trabalhe com modernização em larga escala de sistemas legados, os sistemas de reservas de companhias aéreas são o estudo de caso mais claro disponível sobre o que significa, na prática, "importante demais para falhar".

A Origem: Por que os Mainframes Venceram o Desafio das Companhias Aéreas

O SABRE original (Ambiente de Pesquisa de Negócios Semi-Automatizado) não era um produto, mas sim uma solução personalizada para uma crise operacional específica. No final da década de 1950, a American Airlines estava crescendo mais rápido do que seu sistema de reservas manual conseguia acompanhar. Reservar uma passagem exigia um telefonema, uma verificação manual de um cartão de disponibilidade físico, uma espera, um retorno de chamada e um registro em papel, um processo que levava em média 90 minutos por reserva e não era escalável.

Quando a SABRE entrou em operação plena em 1964, construída sobre dois mainframes IBM 7090 e conectada a 1,500 terminais nos Estados Unidos e Canadá, ela conseguia processar 7,500 reservas por hora com taxas de erro próximas de zero. Pela primeira vez, uma companhia aérea podia manter o inventário de assentos em tempo real, armazenar registros completos de passageiros e permitir reservas instantâneas em toda a sua rede. O tempo de espera para reservas caiu de 90 minutos para segundos.

A escolha arquitetônica que tornou isso possível, o processamento centralizado de transações em hardware mainframe, não foi feita por razões filosóficas. Foi escolhida porque era a única arquitetura disponível em 1964 que atendia aos requisitos de latência, confiabilidade e acesso simultâneo do gerenciamento de inventário de companhias aéreas em tempo real. E funcionou tão bem que se tornou o modelo arquitetônico sobre o qual todos os sistemas de reservas de companhias aéreas subsequentes foram construídos.

O Transaction Processing Facility (TPF) da IBM, originalmente projetado para o SABRE, tornou-se o ambiente operacional para toda a categoria. Quase todos os maiores bancos, seguradoras, varejistas e companhias aéreas ainda o utilizam, segundo a IBM. Quando a Amadeus foi fundada em 1987, ela se baseou no TPF. Quando a Galileo (agora Travelport) lançou seu GDS, também se baseou no TPF. Três gerações de Sistemas de Serviço de Passageiros coexistem na aviação comercial, e muitos ainda operam em mainframes com TPF, não porque a tecnologia nunca tenha sido questionada, mas porque a capacidade de processamento de transações, a confiabilidade e a tolerância a falhas que o TPF oferece em hardware de mainframe provaram ser realmente difíceis de replicar em escala equivalente em arquiteturas alternativas.

O que esses sistemas realmente fazem em grande escala

A escala em que os sistemas de reservas aéreas operam não é intuitivamente compreensível do ponto de vista da engenharia de software. Um sistema de distribuição global não lida apenas com a disponibilidade de assentos, mas também gerencia um problema combinatório de inventário de complexidade impressionante.

Um único voo transatlântico possui centenas de classes tarifárias. Cada classe tarifária tem regras específicas: requisitos de compra antecipada, estadia mínima, datas de restrição, taxas de alteração, escalas permitidas ou não, acordos de codeshare com companhias aéreas parceiras. Uma reserva envolvendo duas companhias aéreas, uma conexão e uma viagem de ida e volta cria uma matriz com potencialmente milhares de combinações tarifárias válidas que devem ser verificadas, precificadas e comparadas com a disponibilidade em tempo real antes que uma resposta seja retornada, geralmente em menos de um segundo.

Durante os períodos de pico de reservas, a Sabre e a Amadeus processam juntas dezenas de milhares de transações por segundo. Não por minuto. Por segundo. Cada transação envolve consulta de disponibilidade em tempo real, avaliação de regras tarifárias, criação ou modificação do PNR (Registro de Nome do Passageiro) e coordenação com os sistemas de controle de embarque, programas de fidelidade e serviços auxiliares. O tempo de resposta garantido é medido em milissegundos, pois um agente de viagens ou mecanismo de reservas que aguarda mais do que alguns segundos por uma verificação de tarifa sofrerá um timeout e tentará novamente ou abandonará a transação.

A TPF em hardware mainframe oferece essa taxa de transferência com uma taxa de falhas que profissionais de TI de outros setores têm dificuldade em acreditar. A tolerância a falhas do mainframe, os processadores redundantes, os componentes hot-swappable e décadas de código de sistema operacional robusto garantem disponibilidade de 99,999% como parâmetro operacional padrão, e não como uma meta aspiracional. Replicar isso a um custo equivalente em infraestrutura de nuvem tem sido o principal desafio técnico de todos os programas de modernização de TI de companhias aéreas tentados desde a década de 1990.

As tentativas de modernização: o que os programas de uma década realmente descobriram

A história da modernização dos sistemas de reservas de companhias aéreas é uma história de programas que se propuseram a substituir o sistema central e que, anos depois, chegaram a um modelo híbrido que, em vez disso, encapsulou o sistema central.

O projeto Jetstream da American Airlines, lançado na década de 2000 com o objetivo explícito de substituir o mainframe PSS da Sabre, acabou optando por adotar um novo produto da Sabre em vez de desenvolver uma alternativa. A premissa inicial de construir ou comprar, de que construir um substituto internamente resultaria em um sistema melhor e mais rápido, esbarrou na mesma realidade que quase todos os grandes programas de substituição de sistemas legados enfrentam: o sistema existente continha requisitos que ninguém conhecia até que o substituto se mostrasse incapaz de atendê-los.

Precisamos ir mais fundo na estrutura e mudar o mecanismo principal, desacoplando as regras para que possamos alterá-las rapidamente. Essa declaração, da liderança de TI da American Airlines durante o programa Jetstream, descreve o problema com precisão. As regras incorporadas no sistema legado — lógica de construção de tarifas, implementações de acordos de codeshare, cálculos de conformidade regulatória, integrações de gerenciamento de receita — acumularam-se ao longo de décadas de mudanças nos negócios e não estavam documentadas de forma alguma que permitisse extraí-las sem executar o sistema existente e observar seu comportamento.

O programa de modernização da Sabre, que começou de fato na década de 2010, levou mais de uma década e custou bilhões de dólares para migrar a maior parte de seu código da infraestrutura de mainframe local. Em 2019, aproximadamente 11% do código da Sabre ainda era executado em data centers locais, com o restante já migrado. Em fevereiro de 2026, a Sabre renovou seu contrato de longo prazo de PSS com a WestJet, demonstrando que, mesmo após uma década de esforços de modernização e bilhões em investimentos, o PSS continua sendo a base comercial do negócio.

A Amadeus alcançou um descomissionamento mais completo de seus mainframes, atingindo o marco de aposentar seus últimos equipamentos em favor da infraestrutura em nuvem. A abordagem da Amadeus, que consistia em substituir incrementalmente os componentes funcionais, mantendo o modelo de dados central e a arquitetura de transações, preservou efetivamente as decisões arquitetônicas originadas no mainframe, mesmo com a mudança de hardware. A semântica das transações, a estrutura de PNR (Registro de Número de Ponto), a lógica de gerenciamento de estoque: tudo isso foi migrado para a infraestrutura moderna, preservando seu design fundamental.

Por que a substituição é mais difícil do que parece: a complexidade oculta

A explicação padrão para a persistência dos sistemas de reservas aéreas em mainframes reside no custo e no risco. Ambos são reais. Mas são sintomas de uma realidade técnica mais profunda que vale a pena compreender com precisão, pois se aplica a todos os programas de modernização de sistemas legados de missão crítica.

Regras de negócio que existem apenas no código. A lógica de construção de tarifas em um sistema de distribuição global representa décadas de requisitos regulatórios, acordos bilaterais entre companhias aéreas, revisões de padrões da IATA e alterações nas regras de negócio, nenhuma das quais está documentada de forma independente do código que as implementa. A especificação é a implementação. Substituir a implementação sem a especificação significa observar o comportamento do sistema existente de forma exaustiva o suficiente para reconstruir o que a especificação teria dito, um processo que leva anos e nunca é concluído, porque a cobertura da observação nunca será abrangente o suficiente para detectar todos os casos extremos.

A semântica das transações é algo que as arquiteturas modernas têm dificuldade em replicar. O TPF (Transaction Processing Framework) oferece processamento de transações síncrono e atômico com consistência garantida em todo o PNR (Registro de Passageiro), reserva de assento, atualização do registro do passageiro, autorização de pagamento e confirmação, tudo confirmado como uma única unidade atômica ou não confirmado. Replicar isso em arquiteturas de microsserviços distribuídas exige orquestração cuidadosa, transações compensatórias e gerenciamento de bloqueios distribuídos, o que é complexo e potencialmente mais lento do que o equivalente síncrono em mainframe. A experiência da indústria aérea mostra que a "consistência eventual" não é uma propriedade tolerável para o inventário de assentos; um voo com excesso de reservas é uma falha concreta e operacionalmente catastrófica, não uma inconsistência temporária a ser resolvida posteriormente.

A superfície de integração. Um PSS (Sistema de Suporte ao Passageiro) consolidado de uma companhia aérea está conectado a centenas de sistemas externos: controle de embarque, gestão de receitas, programas de fidelidade, sistemas aeroportuários, conexões com GDS de terceiros, parceiros de codeshare, relatórios regulatórios e muito mais. Cada conexão possui contratos de interface específicos, formatos de mensagens, requisitos de temporização e comportamentos de tratamento de erros, implementados pelo sistema existente e em torno dos quais todos os sistemas dependentes foram construídos. Substituir o PSS exige manter todos os contratos de interface existentes simultaneamente (o que restringe a arquitetura de substituição) ou coordenar as alterações com todos os sistemas dependentes (o que expande o escopo além da capacidade de qualquer programa individual).

O problema dos dados em tempo real. As reservas aéreas são dados em tempo real, reservas feitas com meses de antecedência que devem ser honradas exatamente como foram feitas. Não existe um ponto de transição simples onde os dados do sistema antigo possam ser simplesmente deixados para trás. A migração deve transferir todos os PNRs (Registro de Nome de Passageiro) em tempo real do sistema antigo para o novo, com todas as regras, tarifas, restrições e serviços adicionais associados intactos. A migração de PNRs em escala global, com garantia de zero perda de dados e comportamento idêntico, tem se mostrado um dos problemas técnicos mais complexos na modernização de empresas.

A resposta arquitetônica: modernizar em torno do núcleo.

A abordagem que de fato obteve sucesso, na Amadeus, na Sabre e em companhias aéreas individuais, não é a substituição, mas sim o encapsulamento estratégico e a extração incremental.

O encapsulamento de API expõe as funções principais de reserva como APIs REST ou SOAP modernas, permitindo que novos aplicativos interajam com o sistema legado por meio de uma interface moderna, sem alterar a lógica central de transações. As companhias aéreas desenvolveram aplicativos móveis, mecanismos de reservas online e ferramentas de atendimento ao cliente com base em camadas de API que traduzem solicitações modernas em chamadas de transação TPF e retornam respostas estruturadas. O terminal de tela verde é substituído por uma interface gráfica moderna; o processamento de transações subjacente permanece inalterado.

A estratégia de estrangulamento (Strangler Fig) visa eliminar funções não essenciais. Funções adjacentes ao núcleo, como gestão de receitas, gestão de programas de fidelidade, relatórios e análises, e planejamento de tripulação, são extraídas uma a uma e reimplementadas em infraestrutura moderna. Cada extração reduz a pegada do sistema legado sem afetar o núcleo de transações, que apresenta o maior risco. Ao longo de uma década de extrações incrementais, o papel do sistema legado se restringe, passando de uma plataforma de aplicativos abrangente para um mecanismo de transações focado.

Infraestrutura em nuvem com arquitetura preservada. O descomissionamento do mainframe da Amadeus migrou as cargas de trabalho para a infraestrutura em nuvem, preservando a arquitetura de transações que se originou no mainframe. O hardware mudou; o design do software, o modelo de dados, a semântica das transações e a estrutura PNR mantiveram as decisões arquitetônicas que se provaram corretas ao longo de décadas.

Nova gestão de ofertas e pedidos em paralelo com o sistema PNR tradicional. O padrão IATA ONE Order, que substitui os registros baseados em PNR por um modelo moderno de gestão de pedidos, está sendo implementado pelas companhias aéreas como uma camada complementar ao sistema PNR existente. As tecnologias de Oferta e Pedido de última geração da Sabre, mencionadas na renovação do contrato com a WestJet em 2026, posicionam essa solução como o caminho a seguir, não a substituição do PSS, mas a adição de uma camada comercial moderna que, eventualmente, crescerá para lidar com uma proporção cada vez maior de reservas, enquanto o núcleo do PNR cuidará do restante.

O que isso significa para qualquer modernização de sistemas legados de missão crítica?

A história do sistema de reservas aéreas não é exclusiva da aviação. É o exemplo mais visível de um padrão que aparece em sistemas centrais de bancos, administração de apólices de seguros, faturamento de telecomunicações e processamento de benefícios governamentais: software que se torna a especificação definitiva das regras de negócio, serve como centro de integração para dezenas de sistemas interdependentes e opera em uma escala e com requisitos de confiabilidade que tornam a substituição completa e radical genuinamente inviável.

As lições são as mesmas em todos os setores:

Extrair as regras de negócio do código, antes de qualquer modernização, não é opcional. Os programas COBOL e TPF que implementam a construção de tarifas, a lógica de acordos de codeshare e as regras de conformidade regulatória são a única documentação remanescente dessas regras. A modernização que não extrai e valida essa lógica previamente não pode produzir uma substituição que se comporte corretamente em todos os casos, pois não é possível conhecer todos os casos sem analisar todo o código.

O mapa de dependências determina a sequência de migração. Nenhuma companhia aérea substituiu com sucesso seu Sistema de Suporte ao Paciente (PSS) começando pelo componente mais crítico e integrado. Toda modernização bem-sucedida começou pelas extremidades — os sistemas de relatórios, os serviços auxiliares, as funções administrativas não críticas — e avançou incrementalmente para o interior. Essa sequência deriva do grafo de dependências: os componentes com o menor número de dependências de entrada são os mais seguros para serem abordados primeiro.

A validação operacional em cada etapa é imprescindível. A abordagem de validação em duas etapas, que consiste em executar o novo sistema em paralelo com o antigo, comparar os resultados e validar a equivalência antes de qualquer transferência de tráfego, é a única que atende aos requisitos de confiabilidade de sistemas em que as falhas acarretam consequências físicas, financeiras e regulatórias.

Como SMART TS XL Aplica-se à análise de legados adjacentes ao setor aéreo.

As companhias aéreas que utilizam Sabre ou Amadeus PSS juntamente com seus próprios programas COBOL, sistemas de cálculo de tarifas, contabilidade de receitas, cálculo de pontos de fidelidade e relatórios regulatórios, enfrentam exatamente o mesmo desafio analítico que todo programa de modernização de mainframe corporativo: entender o que o código realmente contém antes de decidir o que fazer com ele.

SMART TS XL'S análise de código estático Extrai a lógica de regras de negócio incorporada em programas COBOL, as regras de validação de tarifas, os cálculos de contabilidade de receita, a lógica de elegibilidade de níveis de fidelidade, que não existe em nenhum outro lugar além do código do programa. Para companhias aéreas que planejam modernizar sistemas adjacentes sem alterar o núcleo do PSS, essa extração produz a especificação que a substituição deve corresponder.

O mapeamento de dependências da aplicação constrói o grafo de dependências que determina a sequência de migração: quais programas do lado da companhia aérea dependem de quais fluxos de dados do PSS, quais programas de geração de relatórios dependem de quais saídas em lote COBOL e quais sistemas subsequentes devem ser atualizados quando qualquer componente é alterado. O grafo de dependências é o que torna possível a modernização incremental e segura, a mesma abordagem que a Sabre e a Amadeus utilizaram para os sistemas principais, aplicada ao código do lado da companhia aérea que os envolve.

A capacidade de análise de impacto responde à pergunta que precede toda decisão de modernização: se este programa for alterado, o que mais será afetado? Para sistemas de companhias aéreas em que uma alteração de cálculo em um programa de contabilidade de receita pode afetar simultaneamente os relatórios regulatórios, a liquidação com parceiros e a consolidação financeira, conhecer o escopo do impacto antes de qualquer alteração é o pré-requisito para um controle de mudanças que atenda aos requisitos de confiabilidade da companhia aérea.

A análise de modernização de sistemas legados fornece um inventário completo pré-modernização: cada programa em escopo, sua complexidade, suas dependências, a porcentagem de código morto e sua classificação de risco de migração. A lição de todo programa de modernização de companhias aéreas — começar pelas extremidades, trabalhar para dentro e validar a cada passo — requer saber onde estão as extremidades e qual é a estrutura de dependências. Esse conhecimento vem da análise estrutural do código em si, não da documentação escrita antes da evolução do código.

As Camadas Geológicas do Software de Missão Crítica

Ao reservar um voo em um smartphone em 2026, você estará interagindo com um software com múltiplas camadas distintas. A interface moderna na superfície. A camada de API abaixo dela. O mecanismo de transações PSS abaixo disso, executado em uma infraestrutura que mudou substancialmente desde a década de 1960, mas que mantém a semântica de transações e os modelos de dados que eram adequados quando foram projetados e que se provaram confiáveis ​​demais para serem abandonados.

O sistema de reservas aéreas não é um fracasso da modernização. É o resultado de seis décadas de decisões racionais tomadas por engenheiros e executivos que compreenderam, a cada proposta de substituição, que o risco de errar era maior do que o custo de manter o que funcionava. Os sistemas que sobrevivem por tanto tempo o fazem porque conquistam sua posição, transação após transação, voo após voo, temporada de reservas após temporada de reservas.

A lição prática para qualquer equipe de modernização não é que os sistemas antigos nunca devam ser substituídos. É que a decisão de substituí-los deve ser tomada com pleno conhecimento do que eles contêm, do que dependem e qual é, de fato, o escopo total da mudança, e não com estimativas otimistas feitas antes que a complexidade fosse mensurada. A indústria aérea aprendeu isso da maneira mais cara. As ferramentas de análise que produzem conhecimento estrutural completo antes mesmo da primeira linha de código ser escrita são o que tornam possível aprender isso de uma maneira menos dispendiosa.