Design de sistemas
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.
Desenho de sistemas: GPT-5 e Anthropic agrupam-se no topo, Gemini fica atrás
OpenAI
OpenAI
Anthropic
Pontuacao media por modelo
Como ponderamos
Em 35 respostas de desenho pontuadas, o topo é um grupo renhido de GPT-5 e Anthropic. O GPT-5.5 (8,91) e o Claude Opus 4.8 (8,69) ocupam os 1.º e 2.º lugares com registos perfeitos, mas cada um numa única amostra, por isso leia-os como promissores e não consolidados. Os melhores resultados evidenciados são o GPT-5.4 (8,67 em 5 amostras, 60 % de vitórias) e o GPT-5 mini (8,43 em 4 amostras, 75 % de vitórias), que têm aqui o maior peso.
A média e a ordem divergem: o GPT-5.4 supera o GPT-5 mini na média (8,67 contra 8,43) mas fica abaixo, porque o GPT-5 mini vence uma maior proporção dos seus confrontos (75 % contra 60 %). O Claude Sonnet 4.6 (8,53, 60 % em 5) está mesmo neste grupo, por isso os cinco primeiros separam-se por menos de meio ponto em qualidade (8,43 a 8,91) e ordenam-se sobretudo por vitórias diretas. O Claude Haiku 4.5 (8,2, 40 % em 5) segue no 6.º lugar, um degrau abaixo do grupo líder.
A linha Gemini forma um patamar inferior claro: 2.5 Pro (7,51), Flash (7,41) e Flash-Lite (7,12) não vencem nenhum dos seus confrontos e ficam a 1,4–1,79 pontos do líder. Com Qualidade de arquitetura no peso máximo (30) e Raciocínio de compromissos e Escalabilidade (20 cada), a diferença aponta para um raciocínio mais fraco sobre estrutura e compromissos, não para a apresentação.
Os tamanhos de amostra vão de 1 a 6 por modelo, por isso a ordem fina dentro do grupo dos 8 pontos é provisória e alguns prompts podem mover qualquer média. A diferença de 1,79 pontos entre o primeiro e o último é real, mas são medidas dependentes das condições para prompts de desenho, não um veredicto universal.
Resumo
Para desenho de sistemas, o GPT-5 mini é a escolha diária mais defensável (75 % de vitórias em 4 amostras), com o GPT-5.4 como a opção de gama alta mais bem evidenciada (8,67 em 5). O Claude Sonnet 4.6 está praticamente empatado em qualidade; a linha Gemini fica claramente atrás neste género.
Esta analise baseia-se nas pontuacoes de benchmark medidas pela Orivel para este genero e e atualizada periodicamente. As pontuacoes sao medidas dependentes das condicoes, nao uma verdade absoluta.
Ranking de modelos fortes neste genero
Este ranking e ordenado pela pontuacao media apenas dentro deste genero.
Ultima atualizacao: 18 Jul 2026 09:42
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.6 NOVO | OpenAI |
100%
|
90
|
1 | 1 | Ver a avaliacao e a pontuacao de GPT-5.6 |
| #2 | GPT-5.5 | OpenAI |
100%
|
89
|
1 | 1 | Ver a avaliacao e a pontuacao de GPT-5.5 |
| #3 | Claude Opus 4.8 | Anthropic |
100%
|
87
|
1 | 1 | Ver a avaliacao e a pontuacao de Claude Opus 4.8 |
| #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 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Ver a avaliacao e a pontuacao de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
68
|
0 | 5 | 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 Encurtador de URL para 10.000 Requisições por Segundo
Desenhe um serviço de encurtamento de URL (similar em espírito a um produto do tipo 'tiny link') que possa operar com confiabilidade em escala. Apresente sua resposta como um documento de design de sistema estruturado. Requisitos funcionais: - Os usuários submetem uma URL longa e recebem um link curto (por exemplo, um código de 7 caracteres). - Qualquer pessoa que visite um link curto é redirecionada para a URL original. - Apelidos personalizados opcionais solicitados pelos usuários devem ser atendidos se disponíveis. - Análise básica de cliques: contagem total de cliques por link curto. Restrições não funcionais (projetar considerando explicitamente estes números): - Tráfego de pico: 10.000 requisições de redirecionamento por segundo, com uma proporção leitura:escrita de aproximadamente 100:1. - Meta de latência de redirecionamento: p99 abaixo de 50 ms medido no servidor. - Total de links armazenados ao longo de 5 anos: cerca de 30 bilhões. - Meta de disponibilidade de redirecionamento: 99,99% mensal. - Os códigos curtos não devem ser previsíveis em massa (evitar exposição sequencial simples). Seu documento de design deve cobrir o seguinte, e para cada decisão significativa explique a troca (trade-off) que você está aceitando: 1. Arquitetura de alto nível e fluxo de requisição para os caminhos de escrita (criação) e leitura (redirecionamento). 2. Estratégia de geração de código curto, incluindo como você garante unicidade e lida com colisões de apelidos personalizados. 3. Modelo de dados e escolha de banco(s) de dados, com uma estimativa aproximada de capacidade/armazenamento que justifique a escolha. 4. Estratégia de cache e como você mantém links 'quentes' rápidos, incluindo invalidação de cache e o que acontece em um cache miss (acesso não atendido pelo cache). 5. Estratégia de escalonamento: como o caminho de leitura escala para cumprir as metas de latência e taxa, e como você particiona/fragmenta (sharding) os dados. 6. Confiabilidade e tratamento de falhas: o que acontece quando um nó de banco de dados, cache ou região falha; como você atende a meta de disponibilidade. 7. Como as análises de cliques são coletadas sem desacelerar o caminho crítico de redirecionamento. Declare quaisquer suposições que fizer. Mantenha o documento focado e tecnicamente concreto em vez de genérico.
Design de sistemas
Projetar um Sistema de Quadro Branco Colaborativo em Tempo Real
Você foi encarregado de projetar uma arquitetura de sistema de alto nível para uma aplicação de quadro branco colaborativo em tempo real. **Requisitos Principais:** 1. **Colaboração em tempo real:** Vários usuários (até 100 por sessão) podem entrar em um único quadro branco e ver as ações uns dos outros (desenhar, adicionar texto, mover objetos) quase em tempo real (latência inferior a 200 ms). 2. **Persistência:** As sessões do quadro branco devem ser salvas para que os usuários possam fechar a aplicação e retomar seu trabalho mais tarde. 3. **Ferramentas:** Os usuários devem ter ferramentas básicas como uma caneta de forma livre, caixas de texto e notas adesivas. **Restrições de Escala e Confiabilidade:** * Suportar até 10.000 sessões ativas simultâneas de quadro branco. * Suportar até 1.000.000 de usuários no total. * O serviço deve ter alta disponibilidade, com 99,9% de tempo de atividade. **Sua Tarefa:** Forneça um projeto de sistema que atenda aos requisitos acima. Sua resposta deve cobrir: 1. **Arquitetura de Alto Nível:** Um diagrama ou descrição dos principais componentes (por exemplo, clientes, balanceadores de carga, servidores de aplicação, bancos de dados, serviços em tempo real) e como eles interagem. 2. **Comunicação em Tempo Real:** Explique a tecnologia e o protocolo que você usaria para transmitir atualizações a todos os usuários em uma sessão. 3. **Modelo de Dados:** Descreva como você estruturaria os dados de um quadro branco, seu conteúdo (desenhos, texto etc.) e as sessões de usuário. 4. **Estratégia de Escalabilidade e Confiabilidade:** Como você projetaria o sistema para lidar com a carga-alvo e garantir alta disponibilidade? 5. **Trade-offs:** Discuta um trade-off importante que você fez em seu projeto (por exemplo, consistência vs. latência, escolha do banco de dados etc.).
Design de sistemas
Projetar um Sistema Escalável de Reserva de Ingressos para Concerto
Projetar um sistema para uma plataforma online de venda de ingressos para concertos. Os usuários podem navegar por eventos, ver a disponibilidade de assentos, reservar assentos específicos por 10 minutos, pagar por meio de um provedor de pagamento externo e receber um ingresso digital. A plataforma opera em uma região de nuvem única distribuída por múltiplas zonas de disponibilidade. Restrições explícitas: 3 milhões de usuários registrados, 500.000 usuários ativos diários, eventos principais em venda podem atingir 150.000 usuários concorrentes, a carga de pico é de 8.000 tentativas de reserva de assento por segundo e 2.000 tentativas de pagamento por segundo, cada evento tem até 60.000 assentos, o sistema nunca deve vender o mesmo assento duas vezes, reservas de assento expiram após 10 minutos se não pagas, latência p95 para navegação e leituras do mapa de assentos deve ser inferior a 300 ms, latência p95 para confirmação de reserva deve ser inferior a 800 ms excluindo o tempo do provedor de pagamento, meta de disponibilidade durante janelas de venda é 99,95%, objetivo de ponto de recuperação (RPO) é inferior a 1 minuto, objetivo de tempo de recuperação (RTO) é inferior a 15 minutos, e callbacks do provedor de pagamento são do tipo at-least-once, podem chegar fora de ordem e podem ser atrasados em até 5 minutos. Forneça um plano de design. Inclua os principais serviços e armazenamento de dados, APIs centrais, modelo de dados para assentos e reservas, fluxo de requisições para navegação, reserva, pagamento e expiração de reservas, estratégia de escalonamento para picos de tráfego, abordagem de confiabilidade e recuperação de desastres, escolhas de consistência que previnem vendas em duplicidade, monitoramento e alertas, e principais compensações ou alternativas que você considerou. Declare quaisquer pressupostos razoáveis que você fizer.
Design de sistemas
Projetar um Serviço de Notificações Escalável
Você é um engenheiro de software sênior em uma empresa de mídia social em rápido crescimento. Sua tarefa é projetar um serviço de notificações escalável e confiável. Este serviço será responsável por enviar notificações aos usuários sobre vários eventos, como novos seguidores, curtidas em suas publicações, comentários e mensagens diretas.
Design de sistemas
Projetar um Serviço de Notificações em Tempo Real
Descreva um design de sistema em alto nível para um serviço de notificações em tempo real para uma plataforma de mídia social. O serviço deve atender aos seguintes requisitos: - **Escala:** 10 milhões de Usuários Ativos Diariamente (DAU). - **Volume:** Cada usuário recebe em média 20 notificações por dia. - **Latência:** As notificações devem ser entregues no dispositivo do usuário em menos de 2 segundos. - **Canais:** Suporte a notificações push (mobile), e-mail e notificações no aplicativo. - **Confiabilidade:** 99,9% de disponibilidade e nenhuma perda de dados de notificações. Seu design deve cobrir os seguintes aspectos: 1. **Arquitetura Central:** Descreva os componentes chave (por exemplo, API Gateway, Serviço de Notificações, Fila de Mensagens, Trabalhadores) e suas interações. 2. **Esquema de Banco de Dados:** Proponha um esquema básico de banco de dados para armazenar notificações de usuários e preferências. 3. **Estratégia de Escalonamento:** Explique como você escalaria o sistema para lidar com a carga especificada e crescimento futuro. 4. **Confiabilidade e Tolerância a Falhas:** Detalhe as medidas que você tomaria para garantir alta disponibilidade e prevenir perda de dados. 5. **Compromissos Chave:** Discuta pelo menos duas compensações significativas que você fez no seu design (por exemplo, consistência vs. disponibilidade, escolha do banco de dados, modelo push vs. pull).
Design de sistemas
Projetar um serviço de encurtamento de URL
Projetar 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 média da razão leitura-escrita é 100:1 (ou seja, URLs encurtadas são acessadas muito mais frequentemente do que são criadas). 3. URLs encurtadas devem permanecer acessíveis por pelo menos 5 anos após a criação. 4. O sistema deve atingir 99,9% de disponibilidade (uptime). 5. A latência de redirecionamento (desde o recebimento de uma requisição por uma URL curta até emitir o redirecionamento HTTP) deve ser inferior a 50 ms no percentil 95. No seu projeto, aborde todos os seguintes pontos: A. Arquitetura de alto nível: Descreva os principais componentes (servidores de API, bancos de dados, caches, balanceadores de carga, etc.) e como eles interagem. Inclua uma descrição clara do fluxo de requisição tanto para a criação de URL quanto para o redirecionamento de URL. B. Estratégia de geração de URL curta: Explique como você geraria códigos curtos únicos. Discuta as compensações entre diferentes abordagens (por exemplo, hashing, baseado em contador, pools de chaves pré-geradas) e justifique sua escolha. C. Armazenamento de dados: Escolha uma tecnologia de banco de dados e esquema. Estime os requisitos de armazenamento ao longo de 5 anos dadas as restrições. Explique por que o banco de dados escolhido é apropriado. D. Estratégia de escalonamento: Explique como o sistema escala para lidar com o padrão de tráfego fortemente orientado a leitura. Discuta a estratégia de cache, a abordagem de particionamento ou sharding do banco de dados e como você lidaria com chaves quentes (URLs virais que recebem tráfego desproporcional). E. Confiabilidade e tolerância a falhas: Descreva como o sistema mantém 99,9% de disponibilidade. Aborde o que acontece quando componentes individuais falham e como você lida com replicação de dados e failover. F. Principais compensações: Identifique pelo menos duas compensações de projeto significativas que você fez e explique por que escolheu um lado em vez do outro dadas as restrições apresentadas.