Entrevista de Design de Sistemas: Conceba o Uber

"Conceba o Uber" é um dos exercícios de design de sistemas mais comuns porque envolve indexação geoespacial, streaming de localização em tempo real, correspondência (matching) e um elevado throughput de escrita, tudo em simultâneo. O entrevistador não procura a arquitetura real do Uber — quer ver-te a delimitar o problema, a tomar decisões defensáveis e a raciocinar sobre a escala em voz alta.

Siga uma ordem deliberada: esclareça os requisitos, estime a escala, esboce as entidades e APIs principais, conceba os dados e o percurso de correspondência, e depois discuta os pontos de estrangulamento e os trade-offs. O guia abaixo segue essa ordem para que pratique a estrutura, não apenas a resposta.

1. Esclarecer os requisitos

Separe o funcional do não funcional e defina o âmbito antes de conceber. Os passageiros pedem uma viagem e veem o condutor a aproximar-se em tempo real; os condutores ficam online e recebem pedidos próximos; o sistema associa-os e acompanha a viagem até à conclusão.

Funcional: pedir uma viagem, associar a um condutor próximo, acompanhar a viagem em direto, cálculo da tarifa, histórico de viagens.
Não funcional: correspondência de baixa latência (segundos), elevada disponibilidade, atualizações de localização em tempo real, consistência — um condutor atribuído a exatamente um passageiro.
Fora do âmbito (diga-o explicitamente): a vertente interna do processamento de pagamentos, as avaliações, o ML de tarifas dinâmicas — mencione-os e depois adie-os.

2. Estimar a escala

Números aproximados justificam decisões posteriores. Suponha ~10 milhões de condutores ativos diariamente a enviar um sinal de localização a cada 4 segundos — o que dá ~2,5 milhões de escritas por segundo de dados de localização, uma carga dominada pela escrita que exclui de imediato uma tabela relacional simplista como caminho crítico.

3. Componentes principais e APIs

Esboce os serviços e o fluxo de pedidos. Mantenha o percurso de correspondência independente do armazenamento duradouro de viagens, para que cada um possa escalar segundo as suas próprias características.

Serviço de localização: recebe os sinais dos condutores e mantém as posições atuais num índice geoespacial em memória.
Serviço de correspondência: ao receber um pedido de viagem, consulta os condutores online próximos e atribui um.
Serviço de viagens: registo duradouro do ciclo de vida da viagem (pedida → associada → em curso → concluída).
Notificação/streaming: envia a posição do condutor em tempo real ao passageiro (WebSocket/long-poll).

4. Correspondência geoespacial — o cerne do problema

É isto que o entrevistador mais quer ouvir. Armazenar lat/long em bruto e percorrê-los é O(n); é necessário um índice espacial. Explique quadtrees ou geohashing: dividir o mapa em células para que 'encontrar condutores perto deste ponto' passe a ser uma consulta a algumas células, não uma pesquisa completa.

O geohashing codifica uma região numa string curta em que prefixos partilhados significam proximidade espacial, o que transforma 'próximo' numa consulta por prefixo. As células atuais dos condutores residem num armazenamento em memória (por ex. Redis) para leituras rápidas e atualizações frequentes; o tamanho da célula é um trade-off ajustável entre precisão e dispersão das consultas.

5. Escalabilidade e pontos de estrangulamento

Identifique os pontos de pressão e como os aliviaria. O fluxo de 2,5 milhões de escritas de localização por segundo é o mais dominante.

Particione (shard) o índice de localização geograficamente — os condutores e passageiros de uma cidade são tratados pelo mesmo shard, mantendo a correspondência local.
Absorva o pico de escrita com um armazenamento em memória e escritas duradouras assíncronas; não é necessário que cada sinal chegue a uma base de dados duradoura.
Garanta um condutor por passageiro com uma atribuição atómica (um lock ou uma atualização condicional) para evitar reservas duplicadas.
Utilize uma fila de mensagens (Kafka) entre a ingestão de localização e os consumidores a jusante para desacoplar os picos.

6. Trade-offs a verbalizar

Termine identificando as tensões que um entrevistador valoriza: consistência forte vs. eventual (a atribuição do condutor deve ser forte; a exibição da localização pode ser eventual), velocidade em memória vs. durabilidade, e precisão do tamanho da célula vs. dispersão das consultas. Declará-las explicitamente é a diferença entre uma resposta aprovada e uma resposta sólida.

Pratique o design de sistemas do Uber com ajuda em tempo real

O assistente de entrevistas de design de sistemas da Natively pode ajudá-lo a manter-se estruturado durante uma ronda em direto — sugerindo a próxima dimensão a abordar e mostrando os trade-offs em tempo real, tudo no seu próprio dispositivo.