--- title: "Uber Eats reduz pela metade a latência da busca após reconstruir seu pipeline" author: "Lígia Lemos Maia" date: "2026-10-04 07:30:00-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/10/04/uber-eats-reduz-pela-metade-a-latencia-da-busca-apos-reconstruir-seu-pipeline/md" --- ## Resumo - O Uber Eats reduziu em 50% a latência ponta a ponta de seu pipeline de busca em outubro de 2026. - A empresa passou a medir a conclusão Above-the-Fold, que acompanha quando a parte visível da tela está pronta. - A remoção de estratégias de recuperação economizou 120 milissegundos, enquanto renderização assíncrona e paginação reduziram mais de 200 milissegundos. - A hidratação foi separada do ranqueamento e da apresentação, com ganhos superiores a 100 milissegundos. - O caminho de publicidade foi redesenhado com dados em coluna e acesso em memória, gerando um ganho de 130 milissegundos. - Um fluxo de codificação agentic ajudou a identificar gargalos e validar correções, enquanto ajustes em Go reduziram a sobrecarga de garbage collection. - A Uber explora microbatching, Zero Pass Ranking e streaming HTTP multipart para novas reduções de latência. --- Em outubro de 2026, o **Uber Eats** anunciou a reconstrução de partes importantes de seu pipeline de busca, nome dado ao conjunto de etapas que recebe uma consulta, organiza os resultados e prepara a tela final, com uma redução de **50%** na latência ponta a ponta, o tempo entre o pedido do usuário e a conclusão da resposta. A mudança apareceu depois que a equipe deixou de observar somente o tempo de resposta da API de backend, a interface que conecta o aplicativo aos serviços internos, e passou a medir a conclusão Above-the-Fold (ATF), isto é, quando a parte visível da tela está pronta. O resultado pode ser lido em detalhes no [relato técnico sobre a busca do Uber Eats](https://www.infoq.com/news/2026/10/uber-eats-search-latency), que mostra por que a velocidade percebida exigiu uma revisão de várias camadas, e não um único ajuste isolado. ## A velocidade passou a ser medida na tela A equipe trocou a métrica de tempo de resposta da API pela conclusão **Above-the-Fold (ATF)**, uma forma de acompanhar o momento em que o usuário recebe a porção visível da página de resultados. A diferença parece sutil, mas muda a pergunta feita pelos engenheiros: em vez de saber apenas quando um serviço terminou seu trabalho, o objetivo passa a ser identificar quando a experiência que interessa ao usuário está disponível. O próprio material técnico descreve essa troca como parte central do projeto, porque uma resposta rápida no backend não garante, sozinha, que a interface tenha terminado de montar o conteúdo necessário. A busca, nesse caso, é tratada como uma sequência contínua, da consulta até a tela. Essa escolha também ajuda a explicar por que a redução não veio de uma ideia isolada. Segundo o resumo técnico do projeto, os ganhos foram acumulados por decisões incrementais, como a retirada de estratégias de recuperação consideradas de baixo valor, que economizou **120 milissegundos**, e a combinação de renderização assíncrona com paginação, que trouxe uma redução de mais de **200 milissegundos**. Renderização assíncrona significa preparar partes da interface sem obrigar toda a página a esperar pelo mesmo processo, enquanto paginação divide os resultados em blocos carregados conforme necessário. A soma desses movimentos levou a equipe a olhar para cada espera como uma peça de uma engrenagem maior. ## A busca foi desmontada para eliminar esperas Na etapa de recuperação, que seleciona os itens candidatos antes da ordenação final, o Uber Eats removeu estratégias de baixo valor e passou a usar **embeddings de nível de produto**. Embeddings são representações numéricas que permitem ao sistema trabalhar com características de um item durante a busca, embora a fonte não detalhe, nesse anúncio, o modelo específico empregado. A decisão mostra uma tentativa de concentrar o trabalho computacional no que realmente contribui para a lista exibida, em vez de manter caminhos que acrescentavam tempo sem entregar benefício equivalente. A recuperação deixa, assim, de ser uma passagem invisível e passa a ser examinada pelo tempo que acrescenta à experiência completa. Depois da recuperação, a empresa separou a **hidratação do ranqueamento** da hidratação da apresentação. Em linguagem simples, hidratar significa preencher os resultados escolhidos com os dados necessários para que eles sejam exibidos, enquanto ranqueamento é a ordenação desses resultados. Ao separar as duas tarefas, o pipeline pode tratar a decisão sobre a ordem e a montagem visual como trabalhos distintos, em vez de mantê-los presos ao mesmo ritmo. O projeto também incluiu paginação com cache no lado do servidor, recurso que guarda respostas ou partes delas próximo ao serviço que atende às solicitações, reduzindo o trabalho repetido quando novos blocos precisam ser apresentados. ## Publicidade e infraestrutura entraram na conta A publicidade recebeu uma revisão própria porque o caminho dos anúncios também participava do tempo total da busca. O Uber Eats redesenhou essa parte com **dados em coluna**, organização que armazena informações por campo, e acesso em memória, que consulta dados mantidos diretamente na memória do sistema. O resumo técnico atribui ao redesenho da publicidade um ganho de **130 milissegundos**, número que ajuda a dimensionar a influência de uma etapa que poderia parecer secundária para quem observa apenas a lista de restaurantes. Quando a métrica é a conclusão da área visível, cada componente que aguarda a tela passa a ter peso na conta. Em paralelo, o pipeline passou a executar ranqueamento e hidratação de maneira paralela, em vez de manter as duas operações necessariamente em sequência. O ranqueamento define a ordem dos resultados, enquanto a hidratação reúne os dados que permitem apresentá-los ao usuário, e a separação entre essas funções abre espaço para que uma não precise esperar integralmente pela outra. O resumo técnico associa essa separação a uma economia superior a **100 milissegundos**, reforçando a lógica adotada pela equipe: reduzir a latência exigia localizar pequenas filas escondidas entre decisões que pareciam pertencer ao mesmo bloco de trabalho. ## Agentes de IA ajudaram a investigar os gargalos O projeto também utilizou um fluxo de codificação **agentic**, expressão usada para descrever um processo em que um agente de inteligência artificial auxilia na identificação de gargalos e na validação de correções. O blog oficial da Uber descreve esse uso como parte do trabalho de engenharia, não como uma promessa abstrata sobre o futuro do desenvolvimento. A função atribuída ao agente foi apoiar a investigação de pontos lentos e verificar se as mudanças produziam o efeito esperado. Para o time, isso transformou o código em objeto de investigação contínua: cada correção precisava ser confrontada com a métrica que acompanhava a experiência final, e não apenas com a sensação de que um serviço isolado havia ficado mais rápido. [O relato oficial da Uber detalha essa reconstrução](https://www.uber.com/us/en/blog/uber-eats-search-pipeline/). Outra frente atacou o custo interno da linguagem **Go**, usada no sistema. A equipe reduziu a sobrecarga de garbage collection, processo automático que libera memória ocupada por dados que já não são necessários, por meio da alocação de tipos de valor na pilha. A pilha é uma área de memória usada para organizar determinados valores durante a execução, e a escolha descrita pela Uber buscou diminuir o trabalho adicional associado à limpeza automática. O ponto chama atenção porque a latência final também depende de operações que o usuário nunca vê, como o gerenciamento de memória, e não apenas da lógica aparente da busca. A tela rápida é, nesse sentido, o último capítulo de uma história escrita em várias camadas. ## O próximo teste é manter a busca rápida Depois de cortar metade da latência ponta a ponta, a Uber passou a explorar **microbatching**, técnica que reúne pequenas unidades de trabalho para processá-las em lotes curtos, e Zero Pass Ranking (ZPR), abordagem citada pela empresa pelo próprio nome e ainda apresentada como uma frente de ganhos futuros. A formulação do anúncio é cuidadosa: essas tecnologias aparecem como investigações posteriores, não como resultados já incluídos na redução anunciada. Esse detalhe impede uma leitura apressada dos números, porque separa o que foi medido no projeto concluído daquilo que continua em desenvolvimento. A busca, portanto, permanece como uma obra em revisão, na qual cada milissegundo abre uma nova pergunta sobre onde a espera ainda pode ser retirada. A agenda futura também inclui **streaming HTTP multipart**, formato que permite enviar uma resposta em partes, em vez de aguardar que todo o conteúdo esteja pronto para transmiti-lo de uma só vez. O próximo passo prático para equipes que trabalham com sistemas semelhantes é adotar a mesma disciplina de medição: observar a conclusão do conteúdo visível, decompor a jornada em etapas e testar cada intervenção contra um número concreto. No caso do Uber Eats, a sequência anunciada mostra que recuperação, apresentação, publicidade e infraestrutura só fizeram sentido quando avaliadas dentro da experiência completa. A pergunta que permanece não é apenas quanto um serviço demora para responder, mas em que instante a pessoa finalmente consegue usar o resultado que pediu.