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
Anthropic
OpenAI
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 seis primeiros separam-se por menos de meio ponto em qualidade e ordenam-se sobretudo por vitórias diretas.
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,2–1,8 pontos dos líderes. 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: 30 May 2026 09:41
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.5 | OpenAI |
100%
|
89
|
1 | 1 | Ver a avaliacao e a pontuacao de GPT-5.5 |
| #2 | Claude Opus 4.8 NOVO | Anthropic |
100%
|
87
|
1 | 1 | Ver a avaliacao e a pontuacao de Claude Opus 4.8 |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Ver a avaliacao e a pontuacao de GPT-5 mini |
| #4 | GPT-5.4 | OpenAI |
60%
|
87
|
3 | 5 | Ver a avaliacao e a pontuacao de GPT-5.4 |
| #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 |
40%
|
82
|
2 | 5 | 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 | 6 | Ver a avaliacao e a pontuacao de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | 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 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.
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.