Como a autonomia técnica desbloqueou a inovação na Tripadvisor

Quando reservas um bilhete na Tripadvisor para o Oceanário em Lisboa ou para o museu do Louvre, a transação parece instantânea. Por detrás desse clique, centenas de micro-serviços, milhares de operadores e APIs internas e externas comunicam para te providenciar estas experiências em milissegundos.

Durante mais de uma década, o TGDS - o motor de integração com Reservation Systems - operou como um labirinto de 800 mil linhas de código e 100 módulos interconectados que limitava a capacidade de inovação. O projeto COIN (Connected Operators Integration Ngine) decidimos que o tempo de remendar o passado tinha acabado. Era o momento de desenhar o futuro.

O COIN é um ecossistema de integração que desacopla o universo das APIs externas da plataforma internada da nossa plataforma e sistemas internos. Ao estabelecermos uma North Star baseada em stateless, sincronização assíncrona de dados e um rigoroso controlo de fluxo, garantimos uma infraestrutura preparada para recuperar rapidamente de qualquer falha.

A equidade entre fornecedores (Reservation System Fairness) é garantida. A priorização inteligente assegura que uma reserva crítica nunca é travada por uma sincronização de rotina. O resultado? Uma infraestrutura onde a complexidade foi substituída pela clareza, com uma redução de 90% nos incidentes e devolvendo à equipa o poder de inovar sem restrições.

O desafio era modernizar as fundações tecnológicas com o negócio a operar 24/7 e garantir que a Tripadvisor Experiences escala para os próximos 15 anos.

Para conhecermos melhor esta realidade, fomos conversar com Miguel Poço, Technical Manager na Tripadvisor Experiences.

1. Antes de falarmos do projecto, ajuda-nos a perceber a dimensão do desafio: o que acontece nos bastidores quando alguém reserva uma experiência?

Para o cliente, a reserva é o ponto alto das suas férias, para nós é uma orquestração massiva num marketplace bilateral que liga operadores locais a gigantes como Tripadvisor, Viator, Booking.com ou Google.

A complexidade começa muito antes do clique, a nossa arquitetura de sincronização trabalha incessantemente para garantir que preços e disponibilidades de milhares de operadores globais sejam apresentados de forma instantânea.

O COIN atua como o sistema nervoso central e tradutor universal, orquestrando pedidos, validando e reservando o inventário em tempo real para evitar o overbooking, convertendo a intenção do cliente numa comunicação precisa com sistemas externos que variam drasticamente em tecnologia e robustez, garantindo uma experiência fluida e fiável.

2. Trabalhar na Tripadvisor significa lidar com milhares de APIs globais. O que é que isto exige da engenharia?

Trabalhar na Tripadvisor, especificamente na equipa de Conetividade, exige que a engenharia vá muito além da simples escrita de código. Exige uma abordagem assente em três pilares fundamentais:

• Poder de abstração: Lidar com milhares de APIs significa gerir centenas de "dialetos" técnicos e protocolos variados (REST, JSON, SOAP, etc.). A engenharia aqui exige a criação de camadas de abstração robustas que traduzam essa fragmentação global numa linguagem de negócio única, permitindo que o inventário de um pequeno operador local seja processado com a mesma fluidez que o de uma grande multinacional.
• Mentalidade de "desconfiança arquitetural": Como não controlamos os sistemas externos, desenhamos com o pressuposto de que eles vão falhar ou ser lentos. Isto exige o domínio de padrões de resiliência (como Circuit Breakers e Bulkheads) e o uso intensivo de ferramentas de observabilidade (ELK, Grafana, Prometheus). O objetivo é garantir que a latência de um parceiro nunca "contagie" o resto do ecossistema, protegendo os nossos serviços em Kubernetes e AWS.
• Gestão Pragmática de Escala e Recursos: Em conectividade, a escala é massiva (milhões de pedidos/hora). A engenharia precisa de antecipar e mitigar fenómenos como o Head-of-Line (HoL) Blocking, onde a latência ou o volume excessivo de dados de um único parceiro pode tentar monopolizar os recursos da plataforma. Exige-se uma arquitetura que saiba priorizar operações críticas, como a confirmação de uma reserva, em detrimento de atualizações de conteúdo menos urgentes.

3. Tinham um sistema com 800 mil linhas de código que funcionava há 12 anos. Qual foi o "momento da verdade" para decidir que o sistema tinha de ser substituído?

O ponto de ruptura aconteceu quando a manutenção do passado passou a custar mais do que a construção do futuro. Com pipelines de 4 horas e presos a Java 8, a nossa engenharia estava asfixiada: gastávamos 40% do tempo em suporte reativo e os incidentes tinham duplicado num só ano.

Percebemos que já não estávamos a evoluir o sistema, estávamos apenas a tentar impedir o seu colapso. Quando o custo de oportunidade e os limites físicos da infraestrutura se tornaram intransponíveis, ficou claro que remendar já não era uma opção, era necessário modernizar.

4. Reescrever um sistema completo é um risco enorme. Como é que convenceram a organização de que valia a pena em vez de continuar a fazer updates incrementais?

A nossa estratégia para convencer a organização não foi apenas técnica, mas profundamente alinhada com o negócio. O sucesso do argumento assentou em três pilares:

• Primeiro, apresentámos dados empíricos sobre os incidentes e custos insustentáveis do sistema antigo.
• Segundo, construímos um Business Case sólido em parceria com a equipa de Produto para demonstrar o ROI do projecto.
• Por fim, garantimos o alinhamento e partilha de visão de todos os stakeholders de conectividade.

Um dos momentos chave do projecto foi alcançado numa “Collab Week”, um evento em que as equipas da Tripadvisor distribuídas por esse mundo fora se juntam num dos muitos escritórios que temos. A equipa de conectividade, que está sediada em Lisboa, viajou até Oxford no Reino Unido, alcançando um importante alinhamento relativamente à North Star arquitetural com todos os stakeholders. Provámos que o COIN não era um luxo técnico, mas a fundação vital para a Tripadvisor Experiences escalar para os próximos anos.

5. Como é que se gere um projecto destes no dia a dia? Entre deadlines, manter o sistema antigo a funcionar e construir o novo, como é que as equipas se organizam?

Gerir a dualidade entre o passado e o futuro exige um rigor extremo na execução. A nossa estratégia passou por decompor a imensa complexidade das 800 mil linhas de código em pequenas milestones, cada uma encapsulando uma capacidade distinta do serviço (disponibilidades, reservas, sincronização de preços, etc…). Aprendemos que o segredo não está em grandes planos, mas na granularidade: dividimos cada desafio em pequenos tickets com critérios de aceitação rigorosos, o que aumentou drasticamente a nossa previsibilidade.

Mais do que processos, implementámos um sistema de ownership distribuído. Cada engenheiro assumiu a responsabilidade pela entrega de componentes específicos, gerindo o ciclo de vida dessa funcionalidade do início ao fim. Ao termos tarefas claramente definidas e uma cultura de liderança individual, conseguimos reduzir o ruído cognitivo. Isto permitiu-nos manter o ritmo, equilibrando o suporte ao sistema antigo com a construção do COIN de forma autónoma e eficiente.

6. Reconstruir as fundações de um ecossistema global com o negócio a processar reservas 24/7 é um desafio hercúleo. Qual foi a vossa estratégia e que decisões críticas tiveram de tomar?

A nossa estratégia para reconstruir as fundações do sistema sem interromper o negócio assentou numa filosofia de risco zero e validação constante. A decisão mais crítica foi nunca confiar apenas em testes de ambiente controlado. Implementámos uma infraestrutura de Shadow Traffic, onde espelhámos uma percentagem do tráfego real do sistema antigo para o COIN em paralelo. Isto permitiu-nos validar a nova lógica com dados de produção sem que o utilizador final fosse afetado por qualquer erro de crescimento.

Para reforçar esta rede de segurança, introduzimos dezenas de Feature Flags que nos deram um controlo granular e instantâneo sobre cada funcionalidade. Serviram como interruptores de emergência: podíamos ligar o novo sistema para uma percentagem mínima de tráfego e, ao menor sinal de anomalia, reverter para o sistema antigo em milissegundos. Ao combinarmos o tráfego de sombra com rollouts progressivos e uma pirâmide de testes considerável, garantimos que a migração não foi um salto no escuro, mas uma transição controlada onde cada passo foi validado por dados reais.

7. Quando se depende de milhares de integrações externas que podem falhar a qualquer momento, como é que se desenha um sistema que não entra em colapso?

Estes desafios exigem soluções de arquitetura com provas dadas em inúmeros ambientes:

• CQRS (Command Query Responsibility Segregation): Separação clara entre a sincronização massiva de dados dos operadores (escrita) e as pesquisas dos clientes (leitura), garantindo que o processamento de grandes volumes de inventário não prejudique a performance das reservas.
• Circuit Breakers: Mecanismos que detetam instantaneamente se um parceiro externo está com alta latência ou falhas, "abrindo o circuito" para evitar que os recursos do COIN fiquem monopolizados à espera de respostas que não virão.
• Bulkheads (Compartimentação): Isolamento de recursos para que falhas num parceiro não se propaguem. Esta estratégia garante que existe sempre uma quantidade de recursos estritamente reservada para lidar com operações críticas, como a efetivação de reservas, protegendo o núcleo do negócio mesmo sob stress.
• Backpressure management: Um sistema de controlo de fluxo que permite ao COIN gerir a pressão de entrada de dados. Se os sistemas de destino estiverem sobrecarregados, a arquitetura de sincronização sinaliza as fontes para abrandarem o ritmo, prevenindo o colapso do sistema por congestão.

8. Os números impressionam: 90% menos incidentes, 82% mais rápidos a entregar features, 55% de redução em custos. Mas para além das métricas, o que mudou realmente para quem trabalha nas equipas?

Para além das métricas de sucesso, a mudança mais profunda foi o impacto direto na Developer Happiness. Passámos de uma cultura de “combate a incêndios”, onde o stress de lidar com um sistema frágil era constante, para uma cultura de confiança e orgulho técnico.

Hoje, quando um engenheiro faz o release de uma nova funcionalidade, fá-lo com a segurança de que o sistema é robusto e de que existem redes de segurança eficazes. Esta transição do modo reativo para o modo criativo é o que realmente define o sucesso do projecto. Deixámos de gastar energia a “sobreviver” ao código para passarmos a focar a nossa criatividade na resolução de problemas reais. No fim do dia, uma equipa que não vive sob o peso da dívida técnica é uma equipa muito mais feliz, motivada e produtiva.

9. Que competências é que alguém desenvolve ao participar num projecto desta escala? O que aprendeste tu pessoalmente?

Pessoalmente, a maior lição foi perceber que a engenharia de alto nível é 50% arquitetura e 50% comunicação. Aprendi a importância vital de saber envolver os stakeholders, de construir um business case sólido em parceria com o Produto e de manter toda a organização alinhada com a nossa North Star. Foi um exercício profundo de liderança técnica: saber quando ser pragmático, como comunicar o risco e como manter a energia da equipa focada numa visão a longo prazo.

10. Para quem quer trabalhar em engenharia de alto nível e está a avaliar oportunidades, o que distingue genuinamente a Tripadvisor de outras empresas tech?

O que distingue a Tripadvisor é a coragem de dar autonomia real aos seus engenheiros para serem os verdadeiros owners do destino técnico da sua equipa. Projetos como o COIN são a prova viva de que aqui não nos limitamos a manter sistemas, temos a liberdade para propor mudanças radicais, adotar tecnologias de vanguarda e redesenhar o futuro.

Não poderia deixar de falar na cultura de experimentação, na Tripadvisor o foco é validar hipóteses de forma rápida e reagir aos resultados ainda mais rapidamente. Num mercado global onde os grandes players investem milhares de milhões todos os anos para ganhar quota de mercado, a nossa vantagem competitiva é a nossa agilidade intelectual.

11. Para alguém que está a pensar candidatar-se à Tripadvisor e quer trabalhar neste tipo de desafios, que conselhos dás? O que é que procuram nos candidatos?

Procuramos engenheiros que não fiquem paralisados à espera da solução ideal, mas que saibam entregar valor de forma iterativa, aprendendo com os erros e adaptando-se rapidamente quando os requisitos mudam.

Apreciamos engenheiros que não esperem receber uma lista de requisitos por parte de produto ou por parte de stakeholders e queiram fazer parte do processo de definição dos problemas a resolver, no fundo, procuramos Product Engineers.

Valorizamos pessoas que saibam comunicar e que saibam colaborar com colegas para encontrar soluções. Que sejam capazes de demonstrar os tradeoffs de diferentes soluções técnicas utilizando dados e argumentação lógica para persuadir e encontrar a melhor solução em equipa (We Succeed Together).

Se procuras um lugar onde o teu espírito de iniciativa tem impacto direto na estratégia da empresa e onde a complacência não tem lugar, a Tripadvisor é esse espaço.