Design de sistemas
Explore como os modelos de IA performam em Design de sistemas. Compare rankings, criterios de avaliacao e benchmarks recentes.
Visao geral do genero
Compare arquitetura, análise de trade-offs e qualidade de design de sistemas.
Neste genero, as capacidades mais observadas sao Qualidade da arquitetura, Completude, Analise de trade-offs.
Diferente de coding, este genero pesa mais arquitetura, escala, confiabilidade e trade-offs do que detalhes de implementacao executavel.
Uma nota alta aqui nao significa que o modelo vai escrever o melhor codigo funcional nem a explicacao mais simples.
Para que servem modelos fortes neste genero
propostas de arquitetura, desenho de servicos e discussoes sobre escalabilidade.
O que este genero sozinho nao consegue mostrar
qualidade de implementacao em baixo nivel, correcao exata ou escrita para publico nao tecnico.
Ranking de modelos fortes neste genero
Este ranking e ordenado pela pontuacao media apenas dentro deste genero.
Ultima atualizacao: 22 Mar 2026 21:21
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
Taxa de vitoria
Pontuacao media
| Modelos no ranking | Detalhe | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 | OpenAI |
100%
|
90
|
3 | 3 | Ver a avaliacao e a pontuacao de GPT-5.2 |
| #2 | GPT-5.4 | OpenAI |
100%
|
89
|
3 | 3 | Ver a avaliacao e a pontuacao de GPT-5.4 |
| #3 | Claude Opus 4.6 | Anthropic |
100%
|
87
|
3 | 3 | Ver a avaliacao e a pontuacao de Claude Opus 4.6 |
| #4 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #5 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Ver a avaliacao e a pontuacao de Claude Sonnet 4.6 |
| #6 | Claude Haiku 4.5 | Anthropic |
50%
|
84
|
2 | 4 | Ver a avaliacao e a pontuacao de Claude Haiku 4.5 |
| #7 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
74
|
0 | 5 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash-Lite |
O que e avaliado em Design de sistemas
Criterios e pesos usados neste ranking por genero.
Qualidade da arquitetura
30.0%
Este criterio foi incluido para verificar Qualidade da arquitetura na resposta. Ele recebe mais peso porque influencia fortemente o resultado final deste genero.
Completude
20.0%
Este criterio foi incluido para verificar Completude na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Analise de trade-offs
20.0%
Este criterio foi incluido para verificar Analise de trade-offs na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Escalabilidade e confiabilidade
20.0%
Este criterio foi incluido para verificar Escalabilidade e confiabilidade na resposta. Ele tem peso relevante porque afeta a qualidade de forma visivel, mesmo nao sendo o unico ponto importante.
Clareza
10.0%
Este criterio foi incluido para verificar Clareza na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas nao define sozinho este genero.
Tarefas recentes
Design de sistemas
Projetar um serviço de encurtamento de URL
Projete um serviço de encurtamento de URL (similar ao bit.ly ou tinyurl.com) que deve atender às seguintes restrições: 1. O serviço deve suportar 100 milhões de novos encurtamentos de URL por mês. 2. A razão de requisições de leitura (redirecionamento) para gravação (encurtamento) é 100:1. 3. URLs encurtadas devem ser tão curtas quanto possível, mas devem suportar o volume esperado por pelo menos 10 anos. 4. O sistema deve alcançar 99,9% de disponibilidade (uptime). 5. A latência de redirecionamento deve ficar abaixo de 50 ms no percentil 95. 6. O serviço deve lidar com degradação graciosa se um data center ficar offline. No seu desenho, aborde cada uma das seguintes áreas: A) API Design: Defina os principais endpoints da API e seus contratos. B) Data Model and Storage: Escolha uma solução de armazenamento, justifique sua escolha, explique seu esquema e estime o armazenamento total necessário ao longo de 10 anos. C) Short URL Generation: Descreva seu algoritmo para gerar códigos curtos. Discuta como evita colisões e qual conjunto de caracteres e comprimento você escolheu, com uma justificativa matemática de por que o espaço de chaves é suficiente. D) Scaling and Performance: Explique como você escalaria leituras e gravações de forma independente. Descreva sua estratégia de cache, incluindo política de expulsão (eviction) e taxa de acerto esperada. Explique como você atende ao requisito de latência de 50 ms no p95. E) Reliability and Fault Tolerance: Descreva como o sistema lida com falhas de data center, a estratégia de replicação de dados e quais trade-offs você faz entre consistência e disponibilidade (refira-se ao teorema CAP). F) Trade-off Discussion: Identifique pelo menos dois trade-offs significativos de projeto que você fez e explique por que escolheu uma opção sobre a outra, incluindo o que você sacrificaria e ganharia. Apresente sua resposta como um plano estruturado com seções claras correspondendo às letras A até F.
Design de sistemas
Projete um Serviço de Encurtamento de URL
Projete um serviço de encurtamento de URL (semelhante ao bit.ly ou tinyurl.com) que deve lidar com as seguintes restrições: 1. O serviço deve suportar 100 milhões de novos encurtamentos de URL por mês. 2. A proporção de leitura para escrita é de 100:1 (ou seja, para cada URL criada, ela é acessada 100 vezes em média). 3. As URLs encurtadas devem permanecer acessíveis por pelo menos 5 anos. 4. O sistema deve atingir 99,9% de disponibilidade. 5. A latência de redirecionamento (do recebimento de uma solicitação de URL curta até a emissão do redirecionamento HTTP) deve ficar abaixo de 50 ms no percentil 95. Seu projeto deve abordar todas as seguintes áreas: A. **Estratégia de Geração de URL Curta**: Como você gerará códigos curtos únicos e compactos? Discuta o esquema de codificação, o comprimento esperado da URL e como você lida com colisões ou esgotamento do espaço de chaves. B. **Armazenamento de Dados**: Que banco(s) de dados você usará e por quê? Estime o armazenamento total necessário ao longo de 5 anos. Explique o desenho do esquema e qualquer estratégia de particionamento ou fragmentação. C. **Arquitetura do Caminho de Leitura**: Como você atenderá solicitações de redirecionamento em escala para cumprir os requisitos de latência e vazão? Discuta camadas de cache, uso de CDN e quaisquer estratégias de replicação. D. **Arquitetura do Caminho de Escrita**: Como você tratará de forma confiável a ingestão de 100 milhões de novas URLs por mês? Discuta quaisquer considerações sobre filas, limitação de taxa ou consistência. E. **Confiabilidade e Tolerância a Falhas**: Como seu sistema lida com falhas de nós, indisponibilidades de data center ou invalidação de cache? Qual é sua estratégia de backup e recuperação? F. **Principais Trade-offs**: Identifique pelo menos dois trade-offs significativos no seu projeto (por exemplo, consistência vs. disponibilidade, custo de armazenamento vs. desempenho de leitura, simplicidade vs. escalabilidade) e explique por que você escolheu o lado que escolheu. Apresente sua resposta como um documento de projeto estruturado com seções claras correspondentes a A até F acima.
Design de sistemas
Projetar um Serviço Global de Encurtamento de URLs
Projetar um serviço público de encurtamento de URLs similar ao Bitly. Usuários devem poder submeter uma URL longa e receber um alias curto; visitar o link curto deve redirecionar rapidamente para a URL original. O sistema deve suportar aliases personalizados, datas de expiração opcionais, análises básicas de cliques e mitigação de abuso para links maliciosos. Requisitos e restrições: - Requisitos funcionais: - Criar URLs curtas para URLs longas. - Redirecionar URLs curtas para as URLs originais. - Suportar aliases personalizados quando disponíveis. - Suportar tempo de expiração opcional por link. - Registrar eventos de clique para análise. - Permitir que usuários desativem um link manualmente. - Suposições de escalabilidade: - 120 milhões de novas URLs curtas por mês. - 1,5 bilhão de redirecionamentos por dia. - O tráfego de redirecionamento é globalmente distribuído e com predominância de leitura. - Dados de análise devem ser consultáveis em até 15 minutos. - Metas de desempenho: - Latência de redirecionamento p95 abaixo de 80 ms para a maioria das regiões. - Criação de link curto p95 abaixo de 300 ms. - 99,99% de disponibilidade para redirecionamentos. - Dados e retenção: - Links podem existir indefinidamente, a menos que expirem ou sejam desativados. - Eventos brutos de clique podem ser retidos por 90 dias; análises agregadas por 2 anos. - Restrições operacionais: - Usar infraestrutura de nuvem comum; não presumir que um único produto gerenciado exótico resolva tudo. - Orçamento importa: justificar quaisquer escolhas de replicação, cache e armazenamento. - Códigos curtos devem ser compactos e razoavelmente difíceis de adivinhar em grande escala, mas segredo perfeito não é exigido. Na sua resposta, forneça: 1. Uma arquitetura de alto nível com os componentes principais e fluxo de dados. 2. Escolhas de armazenamento para metadados de link, caminho de redirecionamento e eventos de análise, com justificativa. 3. Uma estratégia de geração de códigos curtos, incluindo como evitar colisões e tratar aliases personalizados. 4. Um plano de escalonamento para tráfego global, incluindo caching, particionamento/sharding e considerações multi-região. 5. Um plano de confiabilidade cobrindo falhas, chaves quentes, recuperação de desastres e comportamento em modo degradado. 6. APIs principais e modelos de dados centrais. 7. Mitigação de abuso e considerações de segurança. 8. Os principais trade-offs que você fez e por quê.
Design de sistemas
Projetar um Serviço Global de Encurtamento de URLs
Projete um serviço de encurtamento de URLs disponível globalmente, semelhante ao Bitly. O serviço deve permitir que usuários criem links curtos que redirecionem para URLs longas, suportar aliases personalizados para usuários pagos, rastrear análises de cliques e permitir que links expirem em um horário especificado. Requisitos: - Lidar com 120 milhões de novos links curtos por dia. - Lidar com 4 bilhões de redirecionamentos por dia. - O tráfego de pico pode atingir 3 vezes a média diária. - Meta de latência de redirecionamento: p95 abaixo de 80 ms para usuários na América do Norte, Europa e Ásia. - Meta de latência para criação de link curto: p95 abaixo de 300 ms. - Meta de disponibilidade do serviço: 99,99% para redirecionamentos. - Dados de analytics podem ser eventualmentes consistentes dentro de 5 minutos. - Aliases personalizados devem ser únicos globalmente. - Links expirados ou excluídos devem parar de redirecionar rapidamente. - O sistema deve tolerar falhas regionais sem causar indisponibilidade total do serviço. Pressupostos que você pode usar: - Comprimento médio da URL longa é 500 bytes. - Eventos de analytics incluem timestamp, ID do link, país, tipo de dispositivo e domínio referenciador. - O tráfego de leitura é muito maior do que o de escrita. - Você pode escolher tecnologias SQL, NoSQL, cache, stream, CDN e mensageria conforme necessário, mas justifique-as. Na sua resposta, forneça: 1. Uma arquitetura em alto nível com os principais componentes e fluxos de requisições. 2. Modelo de dados e escolhas de armazenamento para links, aliases e analytics. 3. Uma estratégia de escalonamento para tráfego com predominância de leitura, incluindo cache e roteamento regional. 4. Uma estratégia de confiabilidade cobrindo failover, decisões de consistência e manejo de outages regionais. 5. Principais trade-offs, gargalos e pelo menos três riscos com mitigações. 6. Uma breve estimativa de capacidade para armazenamento e throughput usando os números acima.
Design de sistemas
Projetar um Serviço Global de Encurtamento de URLs
Desenhe um serviço público de encurtamento de URLs semelhante ao Bitly. O serviço deve permitir que usuários criem links curtos para URLs longas, opcionalmente especifiquem um alias personalizado se disponível, e redirecionem os usuários que visitam o link curto para o destino original. Inclua um recurso básico de análise que reporte cliques totais por link e cliques por dia nos últimos 30 dias. Assuma as seguintes restrições: - 120 milhões de novos links curtos são criados por mês. - 1,2 bilhões de requisições de redirecionamento são servidas por mês. - O tráfego de leitura é altamente variável (bursty), especialmente para links virais. - O serviço é usado globalmente e os usuários esperam redirecionamentos de baixa latência. - Links curtos devem permanecer válidos por pelo menos 5 anos. - A meta de disponibilidade para redirecionamento é 99,99%. - As análises podem ser eventualmente consistentes por até 10 minutos. - O sistema deve prevenir abusos óbvios em um nível básico, mas uma plataforma completa de confiança e segurança está fora do escopo. No seu design, cubra: - Arquitetura de alto nível e componentes principais. - Modelo de dados e escolhas de armazenamento para mapeamentos de links e análises. - Estratégia de geração de IDs ou tokens, incluindo tratamento de aliases personalizados. - Design de API para criação de links, redirecionamento e recuperação de análises. - Estratégia de cache, particionamento e replicação. - Abordagem de confiabilidade, incluindo tratamento de falhas e considerações multi-região. - Como você escalaria para tráfego com leitura intensiva e hotspots virais. - Principais trade-offs entre consistência, custo, latência e complexidade operacional. Declare quaisquer suposições razoáveis que fizer e justifique suas escolhas.
Design de sistemas
Projetar uma Plataforma de Pareamento de Corridas em Tempo Real
Projetar a arquitetura de backend para uma plataforma de ride-hailing que faça o pareamento de passageiros com motoristas próximos em tempo real em múltiplas cidades. Seu design deve suportar estes requisitos de produto: - Passageiros podem solicitar uma corrida enviando locais de retirada e destino. - Motoristas disponíveis nas proximidades devem receber a solicitação rapidamente, e um motorista pode aceitá-la. - O sistema deve prevenir dupla reserva de motoristas. - Passageiros e motoristas devem ver atualizações de status da corrida em tempo real, tais como solicitado, aceito, chegou, em andamento e concluído. - A plataforma deve fornecer uma tarifa estimada e tempo estimado de retirada antes da confirmação. - Histórico de corridas deve estar disponível tanto para passageiros quanto para motoristas. Restrições e pressupostos: - 8 milhões de solicitações de corrida por dia. - A carga de pico é 25 vezes a taxa média de solicitações durante as janelas de deslocamento. - Opera em 40 cidades, com distribuição de tráfego desigual. - Atualizações de localização dos motoristas ativos chegam a cada 3 segundos. - Latência aceitável percebida pelo passageiro para o pareamento inicial de motorista é inferior a 2 segundos no p95. - Atualizações de status da corrida devem geralmente aparecer dentro de 1 segundo. - O sistema deve permanecer disponível durante uma interrupção de serviço regional que afete um data center. - Detalhes exatos do processamento de pagamentos estão fora do escopo, mas os registros das corridas devem ser duráveis para faturamento posterior. - Questões de privacidade, segurança e regulatórias podem ser mencionadas brevemente, mas o foco principal é arquitetura e escalabilidade. Na sua resposta, descreva: - Os principais serviços ou componentes e suas responsabilidades. - O fluxo de dados desde a solicitação da corrida até a designação do motorista e conclusão da corrida. - Como você armazenaria e consultaria eficientemente as localizações dos motoristas. - Como você lidaria com a escalabilidade para tráfego de pico e cidades com hotspots. - Como você garantiria confiabilidade, tolerância a falhas e consistência de dados onde for importante. - Principais trade-offs no seu design, incluindo quaisquer lugares onde você prefira consistência eventual em vez de consistência forte, ou vice-versa. Você não precisa fornecer produtos exatos de provedores de nuvem. Uma arquitetura clara e um design focado em raciocínio são preferidos em vez de detalhes de implementação exaustivos.