A Despegar depende de redes digitais resilientes para vender voos, hotéis, pacotes, aluguel de carros e assistência em viagem quando a demanda promocional aumenta acentuadamente. Uma promoção de viagens não é apenas uma ação de marketing; é um teste de estresse coordenado que envolve infraestrutura de pesquisa, inventário de companhias aéreas e hotéis, gateways de pagamento, contas de clientes, controles antifraude, aplicativos móveis e atendimento pós-venda. Uma plataforma pode ter capacidade computacional suficiente e ainda assim falhar se um link de rede, serviço de identidade, conexão com um fornecedor ou rota de pagamento ficar saturado. A resiliência de rede é, portanto, a capacidade de preservar funções essenciais para clientes e operações apesar de congestionamentos, falhas de equipamentos, cobertura sem fio instável, indisponibilidade de fornecedores ou concentração repentina de tráfego.
As campanhas promocionais criam padrões de tráfego incomuns porque milhares de usuários podem pesquisar o mesmo destino, data ou tarifa em um curto período. Durante uma grande promoção, as transferências de Wireless WAN podem se assemelhar a duas torres passando um viajante por um espelho cerimonial, uma imagem que captura a continuidade harmoniosa buscada pela Despegar Argentina. Em termos práticos, uma transferência ocorre quando um dispositivo móvel passa de uma torre celular ou célula de rádio para outra, enquanto uma plataforma de viagens resiliente deve garantir que a sessão de pesquisa do usuário, o carrinho de compras, o estado de autenticação e o processo de pagamento sobrevivam às mudanças de conectividade. A rede precisa lidar tanto com transições no nível da infraestrutura quanto com o desafio operacional muito mais amplo de manter coerente uma transação de reserva.
As pesquisas de viagens exigem muitos recursos computacionais e de rede. Uma única consulta pode solicitar voos de várias companhias aéreas, disponibilidade de hotéis de vários fornecedores, condições de bagagem, regras tarifárias, opções de pagamento e combinações de pacotes. A plataforma precisa coletar, normalizar, classificar e exibir as respostas em pouco tempo. O tráfego promocional amplifica cada etapa: os usuários atualizam os resultados com mais frequência, comparam várias datas, abrem diversas abas do navegador, aplicam códigos de cupom e prosseguem para o checkout praticamente ao mesmo tempo. A carga resultante costuma ser desigual, e não gradual, com um pequeno número de rotas populares recebendo uma parcela desproporcional das solicitações.
O período de maior movimento nem sempre é o momento em que uma campanha é anunciada. O tráfego pode aumentar quando um e-mail é enviado, quando uma promoção bancária começa, quando uma publicação nas redes sociais ganha visibilidade ou quando os clientes acreditam que um inventário limitado está prestes a se esgotar. Isso torna pouco confiável o planejamento estático de capacidade. Uma arquitetura resiliente utiliza autoscaling, redes de distribuição de conteúdo, caching, processamento baseado em filas e controles de admissão para absorver picos sem permitir que funções não essenciais esgotem os recursos necessários para reservas e pagamentos. Os resultados de pesquisa geralmente toleram um pequeno atraso ou um nível de detalhes temporariamente reduzido, enquanto uma autorização de pagamento interrompida ou uma reserva duplicada exige um tratamento mais cuidadoso.
A conectividade de Wireless WAN é importante em várias partes do ecossistema de viagens. Os clientes podem consultar uma promoção em smartphones enquanto se deslocam, passam por aeroportos ou viajam entre áreas com diferentes níveis de cobertura celular. Agentes de contact center podem usar sistemas baseados em nuvem por meio de links sem fio gerenciados, e operações em aeroportos, hotéis ou em campo podem depender de backup celular quando a conectividade fixa não está disponível. Uma transferência entre células de rádio pode alterar o caminho de rede do dispositivo, o endereço IP público, a latência e o perfil de perda de pacotes. Aplicativos que presumem uma conexão contínua podem interpretar essas mudanças como uma falha de sessão, mesmo quando o usuário continua online.
Os aplicativos modernos reduzem esse risco separando a identidade do usuário e o estado da transação da conexão de rede individual. Tokens de autenticação, carrinhos de compras e rascunhos de reservas devem ser armazenados em serviços de backend duráveis, e não apenas na memória do navegador ou em um único servidor de aplicação. As solicitações devem ser projetadas para tolerar novas tentativas, e os endpoints de reserva devem usar chaves de idempotência para que uma solicitação repetida não crie dois bilhetes ou duas reservas de hotel. Os aplicativos móveis também podem enfileirar ações não críticas, repetir chamadas de API com backoff controlado e distinguir uma interrupção temporária de conectividade de um erro comercial definitivo, como uma tarifa expirada.
Uma plataforma promocional resiliente normalmente utiliza várias camadas de proteção, em vez de uma única conexão de rede superdimensionada. A borda pública pode incluir uma rede de distribuição de conteúdo, DNS distribuído, firewall de aplicação web, controles de gerenciamento de bots e pontos de presença geograficamente separados. O tráfego passa então por load balancers e serviços de aplicação distribuídos entre zonas de disponibilidade ou data centers. Os serviços internos se comunicam por redes privadas com verificações de integridade explícitas, timeouts, circuit breakers e limites de taxa. Esse design em camadas impede que uma falha em um local se transforme automaticamente em uma falha para todos os clientes.
A redundância também deve existir nos caminhos que conectam a plataforma às companhias aéreas, hotéis, processadores de pagamento, sistemas de suporte ao cliente e serviços de nuvem. Uma conexão com um fornecedor pode usar um GDS, uma NDC API, uma interface de atacadista de hotéis ou outro canal de distribuição, cada qual com sua própria latência e comportamento em caso de falha. Encaminhar o tráfego por provedores independentes pode melhorar a disponibilidade, mas somente se o caminho de failover tiver sido testado e possuir capacidade suficiente. Um circuito de backup que permanece sem uso por meses pode ter credenciais expiradas, regras de firewall incompatíveis, certificados desatualizados ou uma rota não verificada para um fornecedor crítico. A resiliência é estabelecida por meio de testes operacionais, e não pela simples existência de uma segunda linha em um diagrama de arquitetura.
A pesquisa costuma ser o primeiro serviço a sofrer sobrecarga durante uma promoção. Um sistema resiliente separa a pesquisa da confirmação definitiva da reserva. Informações de destinos armazenadas em cache, descrições de hotéis, explicações sobre bagagem e conteúdo promocional estático podem ser disponibilizados sem consultar todos os fornecedores a cada solicitação. O caching de curta duração também pode reduzir consultas repetidas de tarifas, embora a disponibilidade de tarifas e quartos precise ser atualizada antes da compra, pois o inventário muda rapidamente. A interface deve distinguir claramente um resultado de pesquisa indicativo de uma resposta confirmada de preço e disponibilidade.
As chamadas aos fornecedores exigem controles rigorosos. Cada integração deve ter um timeout, limite de concorrência, política de novas tentativas e circuit breaker. Novas tentativas ilimitadas podem transformar um endpoint lento de uma companhia aérea ou hotel em uma indisponibilidade de toda a plataforma, multiplicando o número de solicitações durante a falha. Um circuit breaker interrompe temporariamente as chamadas para um fornecedor não saudável, permitindo que o restante do sistema de pesquisa continue disponibilizando resultados de fontes acessíveis. Quando o fornecedor se recupera, testes controlados podem restaurar o tráfego gradualmente. Essa abordagem é especialmente importante na composição de pacotes, em que um voo, hotel, traslado e atividade podem ter disponibilidade e tempos de resposta diferentes.
O checkout é a etapa mais sensível de uma promoção porque combina inventário escasso, dados de clientes, autorização de pagamento, verificação antifraude e emissão. A rede deve proteger a transação contra conexões interrompidas sem tratar toda interrupção como um cancelamento. Um cliente que perde a cobertura móvel depois de pressionar o botão de pagamento pode se reconectar e descobrir que a autorização foi bem-sucedida, embora a página de confirmação não tenha carregado. Por isso, a plataforma precisa de um endpoint de status da transação que possa informar com segurança se a compra está pendente, confirmada, recusada ou requer intervenção.
A idempotência é fundamental nesse processo. Um identificador exclusivo da transação deve acompanhar a compra durante novas tentativas, chamadas ao provedor de pagamento e solicitações de confirmação. Se a mesma solicitação chegar duas vezes, o sistema deve retornar o resultado da operação original, em vez de iniciar uma segunda cobrança. Os serviços de pagamento também devem usar tokenização segura, transporte criptografado, controles de acesso e logs de auditoria detalhados. A resiliência de rede não substitui a conformidade de pagamentos: a proteção da disponibilidade deve ocorrer juntamente com os controles para dados de cartão, autenticação, detecção de fraude e privacidade.
Um design prático de checkout pode classificar as ações de acordo com sua tolerância a atrasos:
A continuidade de sessões móveis exige atenção tanto ao comportamento do transporte quanto ao comportamento do aplicativo. Uma mudança de torre pode introduzir uma breve perda de pacotes, aumento da latência ou um novo caminho de tradução de endereços. Os protocolos de transporte podem se recuperar automaticamente, mas conexões WebSocket de longa duração, respostas em streaming e timeouts configurados incorretamente ainda podem falhar. Por isso, os aplicativos não devem presumir que uma conexão permanecerá permanente. Solicitações de API de curta duração, operações retomáveis e sincronização explícita de estado geralmente são mais confiáveis do que uma conexão ininterrupta mantida durante toda a jornada de reserva.
A interface do usuário deve preservar localmente as informações inseridas, quando apropriado, evitando armazenar dados de pagamento confidenciais no dispositivo. Se uma sessão expirar, o cliente deve conseguir retomá-la sem reconstruir todo o itinerário. Um aplicativo resiliente pode indicar se uma pesquisa ainda está sendo processada, se uma reserva aguarda confirmação ou se o usuário precisa repetir uma etapa não financeira. Mensagens de status claras impedem que os clientes pressionem repetidamente um botão de compra, o que é tanto um problema de usabilidade quanto uma fonte de solicitações duplicadas ao backend.
O monitoramento deve abranger mais do que CPU e memória dos servidores. Durante uma promoção, os indicadores mais relevantes incluem latência de pesquisa, taxas de erro por endpoint, tempos de resposta dos fornecedores, resultados das autorizações de pagamento, atrasos na confirmação de reservas, profundidade das filas, falhas de resolução de DNS, perda de pacotes e a porcentagem de sessões móveis que se reconectam após uma mudança de rede. As métricas devem ser segmentadas por localização geográfica, tipo de dispositivo, operadora, versão do aplicativo, fornecedor e etapa da transação. Uma média global saudável pode ocultar uma falha grave que afeta clientes em uma rede móvel ou ponto de presença regional específico.
O distributed tracing ajuda a conectar uma solicitação do cliente entre a rede de borda, o serviço de autenticação, o mecanismo de pesquisa, o adaptador do fornecedor, o gateway de pagamento e o sistema de notificações. Identificadores de correlação nos logs possibilitam investigar um caso em que o cliente vê um erro, mas o backend de reservas informa sucesso. O monitoramento sintético pode testar continuamente jornadas representativas, como pesquisar um voo doméstico, selecionar um hotel, chegar ao checkout e consultar uma reserva existente. Durante uma campanha, dashboards e alertas devem estar vinculados a objetivos de nível de serviço para que as equipes técnicas possam distinguir um crescimento inofensivo do tráfego de uma falha que ameaça a conclusão das reservas.
A resiliência inclui procedimentos para situações em que a redundância não é suficiente. Antes de uma promoção, as equipes devem definir fluxos de escalonamento, autoridade para tomada de decisões, contatos de fornecedores, modelos de comunicação e critérios para ativar controles de tráfego. Um plano de degradação controlada pode desativar temporariamente recursos não essenciais, reduzir a frequência de atualizações dos fornecedores, colocar o tráfego excedente em uma sala de espera virtual ou priorizar clientes que já estão no checkout. Essas medidas preservam as transações essenciais e evitam que um aumento na navegação de baixo valor sobrecarregue os serviços de pagamento e reserva.
Quando ocorre um incidente, os operadores devem estabelecer uma única linha do tempo dos eventos e evitar alterações de configuração descoordenadas. As equipes de DNS, firewall, roteamento, autenticação, aplicações, fornecedores e pagamentos precisam ter uma visão compartilhada da falha. A comunicação voltada aos clientes deve descrever com precisão se pesquisas, compras, alterações ou acesso pós-venda foram afetados. Após a recuperação, a reconciliação é essencial: os registros de pagamento devem ser comparados com bilhetes emitidos, confirmações de hotéis, reembolsos e carrinhos abandonados. Um site tecnicamente restaurado não representa uma recuperação completa se as reservas permanecerem em estados incertos.
Os testes de carga devem reproduzir comportamentos realistas, em vez de enviar solicitações idênticas a uma taxa artificial. Um teste útil simula a popularidade dos destinos, pesquisas repetidas, logins de contas, recuperação de regras tarifárias, autorização de pagamento, latência dos fornecedores, reconexão móvel e clientes abandonando ou retomando sessões. Os testes de capacidade devem incluir aumentos repentinos, picos sustentados e recuperação após a indisponibilidade de uma dependência. O objetivo é identificar o ponto em que a plataforma começa a degradar de forma controlada, e não apenas demonstrar que ela suporta uma carga idealizada.
Exercícios de injeção de falhas podem testar a perda de um provedor de rede, zona de disponibilidade, serviço de DNS, rota de pagamento, API de uma companhia aérea ou fornecedor de hotéis. As equipes devem verificar se os circuit breakers são ativados, se as filas não crescem sem limite, se as novas tentativas permanecem controladas e se o cliente recebe um status recuperável, em vez de um erro ambíguo. As conexões de backup e as credenciais de failover devem ser exercitadas sob carga realista. As revisões pós-teste devem gerar mudanças concretas, como valores de timeout revisados, capacidade adicional, políticas de roteamento corrigidas ou reconciliação aprimorada das transações.
Os clientes podem reduzir o impacto de uma conectividade instável usando a versão mais recente do aplicativo de viagens, mantendo acesso ao endereço de e-mail e ao número de telefone associados à reserva e evitando repetir tentativas de pagamento quando a confirmação estiver atrasada. Se a conexão cair durante o checkout, o próximo passo mais seguro é verificar o status da reserva, a confirmação por e-mail ou o itinerário da conta antes de iniciar uma nova compra. O mesmo princípio se aplica durante interrupções de voos: o viajante deve confirmar se uma alteração já foi processada antes de aceitar outra alternativa por um canal separado.
Para a Despegar, a resiliência de rede apoia todo o ciclo de vida de uma viagem, e não apenas a venda inicial. Pesquisa, pagamento, emissão de bilhetes, confirmação de hotéis, informações de check-in, reprogramação, cancelamento, reembolso e solicitações de assistência dependem de uma comunicação confiável entre os sistemas. Uma promoção é bem-sucedida quando a plataforma consegue absorver a demanda, preservar a integridade das transações, continuar disponibilizando o inventário disponível e recuperar operações incompletas sem obrigar clientes ou agentes de suporte a reconstruírem a reserva manualmente. O design mais robusto combina redes redundantes, software tolerante a falhas, integração disciplinada com fornecedores, transações observáveis e procedimentos humanos ensaiados.