# System Design da Uber: Estudo de Caso em 2025

> Published 2026-10-12T22:57:15.647Z on https://youblog.app/p/system-design-da-uber-estudo-de-caso-em-2025/
> Source video: https://www.youtube.com/watch?v=ihqhIo7Pql0

O estudo de caso de system design da Uber apresentado no evento Full Cycle Tech Week é um exercício de modelagem sobre um domínio de compartilhamento de veículos. Ele passa por requisitos, capacidade, entidades core, API e visão high level, e serve tanto para entrevistas quanto para projetos reais.

## System design da Uber: o que o estudo de caso cobre

O system design da Uber usado no evento Full Cycle Tech Week é um exercício de modelagem sobre o domínio de compartilhamento de veículos, conduzido em cinco etapas antes do diagrama final. Wesley Willians, instrutor da Full Cycle, apresenta a proposta no vídeo de divulgação publicado em 17 de janeiro de 2025. O vídeo descreve o evento como online, gratuito e fechado no Zoom, com início marcado para o dia 20 de janeiro de 2025, das 20h00 às 21h00 (horário de Brasília).

A escolha da Uber como estudo de caso se apoia em um domínio conhecido: alocação de motorista, cálculo de rota, preço dinâmico, rastreamento em tempo real e histórico de viagens. Cada um desses pontos gera perguntas técnicas distintas de particionamento, latência, consistência e volume de escrita. O vídeo não desenvolve o conteúdo das aulas, apenas descreve a estrutura da trilha e os materiais que acompanham cada etapa. As aulas preparatórias já ficaram disponíveis na plataforma da Full Cycle no momento da inscrição, para estudo anterior à semana do evento.

Vale registrar uma ressalva de escopo. O vídeo é um anúncio de evento, não um documento com números auditáveis. Nenhuma estimativa de volume, latência ou custo aparece no material publicado. Qualquer número usado neste artigo vem dos materiais oficiais de arquitetura da Uber, na seção em que é citado, e não do vídeo.

A separação entre o produto core e as camadas de plataforma aparece na engenharia real da empresa. A Uber publica material técnico sobre serviços, armazenamento e infraestrutura, e essa base ajuda a testar se um desenho proposto faz sentido. Use essas fontes para validar premissas de volume e não para copiar arquitetura alheia sem contexto.

O que muda de um evento para um projeto real é o tempo de vida das decisões. Um desenho de system design da Uber pode ser refeito inúmeras vezes em uma sala de aula. Em produção, cada escolha de partição e de modelo de consistência tem custo operacional e migração posterior. O valor do exercício está em treinar o raciocínio que antecede a escolha tecnológica.

### Onde encontrar a fonte e o material do evento

O vídeo de divulgação está no [canal da Full Cycle no YouTube](https://www.youtube.com/watch?v=ihqhIo7Pql0). A documentação técnica usada como referência de escala está no [blog de engenharia da Uber](https://www.uber.com/en-US/blog/engineering/), que mantém posts com data explícita sobre a plataforma de dados e o serviço de viagens. Três fontes, três contextos: o vídeo descreve o evento, o blog da Uber descreve o sistema em produção, e a plataforma da Full Cycle entrega as aulas preparatórias.

## As cinco etapas antes do diagrama

As cinco etapas do estudo de caso são requisitos de engenharia, plano de capacidade, entidades core, design de API e visão high level. O vídeo lista essa sequência como o conteúdo preparatório entregue a quem se inscreveu. O diagrama aparece ao final, depois que as premissas numéricas já estão escritas.

A sequência funciona como um funil, e não como uma lista de tópicos. Cada etapa reduz o espaço de decisão da seguinte:

1. **Requisitos de engenharia:** fixe latência alvo por operação, disponibilidade, durabilidade, consistência exigida e escopo funcional. Nada de tecnologia nesta etapa.
2. **Plano de capacidade:** traduza os requisitos em usuários ativos, viagens por segundo no pico, leituras por escrita, tamanho de payload e retenção.
3. **Entidades core:** desenhe as fronteiras dos dados antes dos serviços. Motorista, passageiro, viagem, rota, pagamento e evento de telemetria pertencem a agregados diferentes.
4. **Design de API:** feche os contratos de leitura e escrita, com idempotência, paginação, versionamento, formato de erro e limites de taxa.
5. **Visão high level:** só agora organize serviços, armazenamento, fila e camada de consulta. O diagrama é consequência das quatro etapas anteriores.

Esse formato também serve para entrevistas de system design em big tech, como o próprio vídeo indica. A diferença é o tempo disponível e a profundidade cobrada em cada etapa. Em uma entrevista, requisitos e API costumam pesar mais do que a escolha de banco de dados, porque o entrevistador quer ver o raciocínio de decomposição.

Uma armadilha comum é começar pela caixa do meio. Escolher Kafka, Cassandra ou Postgres antes de saber o padrão de leitura e a garantia de consistência leva a revisões caras mais adiante. O exercício da Full Cycle trata justamente dessa sequência inversa.

### Cinco etapas aplicadas à operação de uma viagem

A tabela abaixo mostra como cada etapa muda de pergunta conforme a operação. Use-a como checklist durante o exercício.

| Etapa | Pergunta que ela responde | Artefato de saída |
| --- | --- | --- |
| Requisitos de engenharia | O que o sistema precisa garantir? | Lista de latência, disponibilidade e consistência por operação |
| Plano de capacidade | Quanto tráfego e quanto dado? | Escritas e leituras por segundo no pico, item médio, retenção |
| Entidades core | Quais são as fronteiras dos dados? | Modelo de agregados e identificadores |
| Design de API | Como o cliente lê e escreve? | Contrato com idempotência, paginação e versionamento |
| Visão high level | Quais componentes sobram? | Diagrama de serviços, armazenamento, fila e consulta |

## Requisitos de engenharia e plano de capacidade

Requisitos de engenharia definem o que o sistema precisa garantir antes de qualquer escolha de tecnologia; plano de capacidade traduz esses requisitos em números. O vídeo cita os dois como parte do material preparatório do evento realizado em janeiro de 2025.

A Uber publica números que ajudam a calibrar ordens de grandeza. Em material de engenharia sobre a plataforma de dados, a empresa descreve um sistema que processa trilhões de mensagens por dia e petabytes de dados armazenados. Esses números são vendor-reported, medidos pela própria Uber, e servem como referência de escala, não como meta para o seu projeto.

A Uber descreve publicamente o modelo de dados do serviço de viagens, com tabelas centrais documentadas no [blog de engenharia](https://www.uber.com/en-US/blog/engineering/). Esse tipo de fonte primária substitui a intuição sobre cardinalidade e ajuda a estimar partições. Atribua qualquer número diretamente à empresa e verifique a data do post.

No plano de capacidade, quatro contas precisam estar no papel:

- **Pico de escrita:** eventos de telemetria por segundo na hora de maior demanda da cidade ou região.
- **Pico de leitura:** consultas de histórico e cálculo de preço por segundo, que raramente coincidem com o pico de escrita.
- **Item médio:** bytes por evento de telemetria e por registro de viagem, incluindo índices.
- **Retenção:** por quanto tempo cada tabela precisa guardar dados, por exigência de produto e de regulação.

A relação leitura por escrita em um app de mobilidade varia por operação. Rastreamento de posição gera escrita contínua; consulta de histórico gera leitura pontual; cálculo de preço combina ambos.

A Uber opera um sistema de rastreamento de frota em tempo real que recebe dados de posição continuamente. Esse fluxo é o principal consumidor de escrita em qualquer modelo desse domínio. Se você modelar esse volume com um número genérico de usuários ativos, o dimensionamento de partição erra por ordem de grandeza. Um exemplo do erro: assumir 1 evento por viagem em vez de 1 evento por segundo por veículo ativo infla ou encolhe a partição em várias ordens de magnitude.

## Entidades core e design de API

Entidades core e design de API definem os contratos que sobrevivem a trocas de tecnologia; o estudo de caso as trata antes da visão high level. O vídeo do evento Full Cycle Tech Week de janeiro de 2025 cita as duas etapas na sequência de aulas preparatórias.

A Uber descreve sua própria modelagem de viagens em material de engenharia, incluindo esquemas de dados e evolução de tabelas. Essa documentação mostra como um identificador de viagem atravessa estados: solicitada, aceita, em andamento, concluída, cancelada. Um desenho coerente precisa preservar essa máquina de estados na API, com transições explícitas e rejeição de saltos inválidos.

Idempotência é o primeiro item do design de API nesse domínio. Uma requisição de solicitação de viagem pode ser reenviada por falha de rede, e duas viagens criadas para o mesmo passageiro é um erro caro. Chave de idempotência com janela de deduplicação resolve a maior parte dos casos, mas exige armazenar a chave e o resultado por tempo suficiente para cobrir retentativas do cliente.

Paginação por Cursor funciona melhor que offset em histórico de viagens e telemetria, porque o volume cresce continuamente e o offset degrada. Versionamento explícito no caminho da URL permite que clientes móveis antigos continuem funcionando durante o ciclo de atualização da loja.

Limites de taxa protegem o serviço de picos de cliente, mas também criam uma decisão: rejeitar ou enfileirar. Em fluxos de solicitação de viagem, rejeitar com erro claro costuma ser melhor que enfileirar sem confirmação, porque o usuário precisa saber se a solicitação foi aceita. Em fluxos de telemetria, o oposto faz sentido: enfileirar e descartar amostras antigas é aceitável, porque perder um ponto de posição não quebra a viagem.

### Decisões de API e o que cada uma custa

| Decisão | Escolha comum | Custo ou trade-off |
| --- | --- | --- |
| Idempotência | Chave por requisição com janela de deduplicação | Armazenamento extra por chave e resultado |
| Paginação | Cursor em vez de offset | Cursor opaco, mais difícil de depurar manualmente |
| Versionamento | Versão no caminho da URL | Manutenção de duas versões durante a migração |
| Limite de taxa em solicitação de viagem | Rejeitar com erro claro | Pico de usuário legítimo recebe erro e precisa tentar de novo |
| Limite de taxa em telemetria | Enfileirar e descartar amostra antiga | Perda de pontos de posição, aceitável para o produto |

## Visão high level e limites de consistência

A visão high level organiza serviços, armazenamento e camada de consulta depois que requisitos, capacidade, entidades e API estão definidos. O vídeo descreve essa etapa como o fechamento do estudo de caso baseado na Uber apresentado em janeiro de 2025.

A Uber documenta publicamente parte de sua infraestrutura de dados, incluindo sistemas de armazenamento distribuído para cargas analíticas e operacionais. Essa transparência parcial permite testar o desenho proposto contra uma arquitetura real, mas não substitui a leitura das decisões de negócio por trás de cada componente.

Consistência é a dimensão que mais gera discussão nesse tipo de desenho. A alocação de motorista exige leitura atualizada do estado da frota na região relevante. O histórico de viagens aceita consistência eventual sem prejuízo visível para o usuário. Cálculo de preço e faturamento exigem precisão contábil.

Um erro frequente é aplicar o mesmo modelo de consistência a todas as entidades. Isso simplifica o diagrama e encarece a solução. A pergunta certa é qual operação de negócio quebra se a leitura estiver alguns segundos atrasada.

Dados regulatórios mudam a resposta. Registros de viagem podem ter exigência de retenção e auditoria definida por jurisdição, e a Uber opera em mercados com regras distintas. Nenhuma arquitetura técnica por si só garante conformidade; ela apenas viabiliza os controles que a aplicação e a organização precisam implementar.

## Full Cycle Tech Week for Seniors: formato e público

O Full Cycle Tech Week for Seniors foi um evento online, gratuito e fechado no Zoom, com aulas ao vivo das 20h00 às 21h00 entre 20 e 23 de janeiro de 2025. O vídeo de divulgação foi publicado em 17 de janeiro de 2025 no canal da Full Cycle, escola brasileira de programação conhecida pelos cursos de Go, Kafka, gRPC e system design.

A transmissão ocorreu na plataforma da própria Full Cycle, a mesma usada pelos alunos pagantes. Quem se inscreveu recebeu por e-mail o acesso a um módulo específico, com capítulos liberados ao longo dos dias do evento e material adicional anexado às aulas. Wesley Willians descreve o formato como novo para a própria escola: metodologias que a Full Cycle usa nos cursos e no MBA foram adaptadas para um evento gratuito.

A segmentação de público foi explícita no vídeo. O conteúdo foi direcionado a desenvolvedores sênior, tech leads e tech managers, com a ressalva de que iniciantes provavelmente não aproveitariam o material. Essa restrição é comum em eventos técnicos que partem de premissas de experiência.

O formato previsto incluía divisão dos participantes em salas virtuais menores em alguns momentos, para networking e discussão de desafios, com retorno à sala principal para aprofundamento. Wesley Willians também anunciou uma mentoria gratuita no último dia, com foco em carreira e dúvidas técnicas.

Uma característica do formato é a pluralidade de visões. Como o vídeo menciona, cada desenvolvedor projeta sistemas de forma diferente, e outros participantes poderiam apresentar suas próprias abordagens sobre o mesmo problema. Isso contrasta com a resposta única de tutorial.

## Como aplicar esse estudo de caso em 2026

Aplicar o estudo de caso em 2026 significa manter a sequência de cinco etapas e substituir as referências de escala pelas do seu próprio produto. O evento de 2025 é o ponto de partida metodológico; os números mudam com o seu contexto.

A Uber atualiza continuamente sua documentação de engenharia, e os posts usados como referência aqui têm datas específicas. Ao citá-los, verifique se a informação ainda corresponde ao sistema em operação, porque arquiteturas evoluem e componentes são substituídos.

Em um projeto pequeno, as cinco etapas cabem em uma reunião de uma hora. Em um sistema em produção, elas viram um documento vivo, revisado a cada mudança relevante de requisito. O que não muda é a ordem: primeiro as premissas, depois o diagrama.

Para entrevistas, a prática de escrever os números antes do desenho reduz a chance de improviso. Para o dia a dia, ela expõe cedo os pontos em que o time discorda sobre o que o sistema precisa garantir.

## FAQ

### O que é o estudo de caso de system design da Uber apresentado pela Full Cycle?

É um exercício de modelagem sobre o domínio de compartilhamento de veículos, conduzido em cinco etapas: requisitos, plano de capacidade, entidades core, design de API e visão high level. O evento que o apresentou ocorreu entre 20 e 23 de janeiro de 2025 no Zoom.

### Por que usar o domínio da Uber em um exercício de arquitetura?

Porque o domínio combina escrita contínua de telemetria, alocação em tempo real, cálculo de preço e histórico de longa duração. Essas operações exigem decisões de consistência e particionamento diferentes entre si, o que rende discussão técnica.

### Preciso de experiência sênior para aproveitar esse tipo de conteúdo?

O próprio vídeo de divulgação recomenda o material para desenvolvedores sênior, tech leads e tech managers. Iniciantes tendem a não aproveitar porque as aulas partem de premissas de experiência em microsserviços e integração.

### Quais são as cinco etapas antes do diagrama de arquitetura?

Requisitos de engenharia, plano de capacidade, entidades core, design de API e visão high level. O diagrama aparece depois, quando as premissas numéricas e os contratos já estão escritos.

### Como estimar capacidade em um sistema de mobilidade?

Comece pelo pico de escrita de telemetria, depois o pico de leitura em consultas de histórico e cálculo de preço. A Uber publica referências de escala em seu blog de engenharia, mas esses números são da própria empresa e servem apenas como ordem de grandeza.

### Onde encontrar o material de system design mencionado no vídeo?

O material preparatório ficou disponível na plataforma da Full Cycle após a inscrição no evento, com aulas liberadas ao longo dos dias. O vídeo de divulgação foi publicado em 17 de janeiro de 2025 no canal da Full Cycle.

### O estudo de caso serve para entrevistas de big tech?

Sim, o vídeo cita esse uso explicitamente. A diferença é o tempo disponível e o peso dado a cada etapa, com requisitos e design de API ocupando mais espaço que a escolha de banco de dados.

### Por que definir requisitos antes de escolher banco de dados ou fila?

Porque a escolha de tecnologia deriva do padrão de leitura, do volume de escrita e da garantia de consistência exigida. Escolher antes de definir esses pontos leva a revisões caras quando a premissa se mostra errada.

### O conteúdo gera certificado ou diploma?

O vídeo de divulgação não menciona certificado. Ele descreve o evento como gratuito, fechado no Zoom, com aulas ao vivo das 20h às 21h e uma mentoria gratuita no último dia sobre carreira e dúvidas técnicas.

### O que mudou no estudo de caso entre 2025 e 2026?

A metodologia de cinco etapas continua válida, mas os números de escala e os componentes citados pela Uber evoluem. Ao usar uma referência técnica, confira a data do post original antes de reaproveitar os valores.

### Quem é Gustavo Dev Doido e como ele se relaciona com esse conteúdo?

Gustavo Dev Doido é um criador de conteúdo brasileiro conhecido na comunidade de desenvolvimento por vídeos e materiais técnicos. Ele mantém iniciativas como o Bootcamp do Dev Doido e a Crazystack, com destaque para a formação em [Crazystack Typescript](https://crazystack.com.br), que aborda desenvolvimento full stack com TypeScript. Esses materiais tratam de trilhas de estudo e prática, não de benchmark de arquitetura da Uber.

[Source video](https://www.youtube.com/watch?v=ihqhIo7Pql0)

## Transformar uma aula em artigo

O estudo de caso da Uber só funciona porque alguém separou requisitos, capacidade, entidades, API e visão high level antes de desenhar qualquer caixa. Esse mesmo tipo de conhecimento costuma ficar preso em vídeos longos no YouTube, onde a explicação existe mas não está escrita em lugar nenhum. Se você tem aulas, entrevistas ou análises técnicas gravadas nesse formato, o [Skala Blog](https://skalablog.com) faz o caminho inverso: você cola a URL do vídeo, ele transcreve e gera um artigo estruturado, pronto para revisar e publicar.