Busca mais rápida no Uber Eats: antes de escalar, descubra o trabalho que pode desaparecer

A Uber relata redução de 50% na latência de ponta a ponta da busca do Uber Eats após intervenções em recuperação, atributos, ranking, anúncios, apresentação e infraestrutura.[15] O resultado é descrito como combinação de melhorias incrementais, não efeito de uma única troca de arquitetura.[15] Para quem desenvolve, o ângulo útil é localizar trabalho desnecessário antes de comprar mais capacidade.

O que muda para quem desenvolve

A equipe passou a medir Above-the-Fold, o momento em que a primeira tela de resultados com imagens está pronta, em vez de priorizar apenas a resposta da API.[15] Paginação com cache no servidor e renderização assíncrona melhoraram essa métrica em mais de 200 ms.[15]

Na recuperação, dezenas de milhares de candidatos recebiam atributos antes do ranking e eram depois descartados.[15] Remover estratégias de pouco valor economizou cerca de 120 ms, enquanto separar atributos de ranking dos dados de apresentação reduziu mais de 100 ms.[15]

Minha leitura é que uma medição local rápida pode conviver com experiência lenta se ignorar volume inicial, dependências e renderização. O modelo mental recomendado é um grafo do que precisa acontecer até a primeira informação útil, não uma coleção de endpoints avaliados isoladamente.

Como aplicar

Escolha uma tela de busca ou listagem e estabeleça uma linha de base com a mesma carga de teste. Registre tempo de API, tempo até a primeira tela utilizável, quantidade de candidatos e volume de dados carregados. Use consultas representativas, incluindo resultados vazios e buscas amplas.

Proponho um experimento específico: separe os campos necessários ao ranking daqueles usados apenas na apresentação. Carregue o segundo grupo somente para os resultados selecionados e compare latência, qualidade da ordenação e consumo. O resultado só deve ser aceito se preservar a função esperada.

Depois desenhe dependências entre etapas. Procure serializações que possam ser removidas sem comprometer consistência. Faça uma mudança por rodada e compare mediana, p95 e p99, além de erros. Uma redução média que piora sistematicamente a cauda pode ser uma troca ruim para o produto.

Cuidados e limites

Os tempos divulgados são medições das intervenções no sistema da Uber e não devem ser somados como ganhos independentes nem tratados como promessa para outra aplicação.[15] O resultado inicial de mais de 50% de redução no p99 para busca baseada em produto é experimental e distinto da redução geral anunciada.[15]

Requisições redundantes controladas também aparecem entre as otimizações relatadas.[15] Antes de adotar esse tipo de estratégia, recomendo medir consumo adicional e comportamento sob saturação. Reduzir espera de uma chamada pode aumentar carga total. A prioridade é remover trabalho sem valor, antecipar o que pode começar e validar o efeito percebido pelo usuário.

Fonte

[15] Fonte: InfoQ