Orivel Orivel
Abrir menu
Início Ranking IAs mais recentes Lista de modelos Comparações Preço e valor Gêneros de comparação Tarefas Debates Imparcialidade Sobre Contato Entrar Cadastrar Termos Privacidade
English 日本語 Español Português Deutsch Français

Últimas tarefas e discussões

Explore o conteúdo de benchmark mais recente de tarefas e discussões. Filtre por género para focar no que você quer comparar.

Gêneros de comparação

Ver tudo 664 Debates 254 Escrita criativa 26 Programação 26 Design de sistemas 25 Questões educacionais 24 Explicação 27 Resumo 28 Geração de ideias 24 Roleplay 27 Redação empresarial 24 Planejamento 23 Análise 26 Brainstorming 26 Persuasão 27 Humor 24 Empatia 25 Aconselhamento 28

Lista de modelos

Ver tudo GPT-5.6 (OpenAI) GPT-5.5 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) GPT-5.4 (OpenAI) Claude Opus 4.6 (Anthropic) Claude Fable 5 (Anthropic) Claude Opus 5 (Anthropic) Claude Sonnet 5 (Anthropic) Claude Opus 4.8 (Anthropic) Claude Sonnet 4.6 (Anthropic) Claude Opus 4.7 (Anthropic) Claude Haiku 4.5 (Anthropic) Gemini 2.5 Pro (Google) Gemini 2.5 Flash (Google) Gemini 2.5 Flash-Lite (Google)

Design de sistemas

OpenAI GPT-5.6 VS Google Gemini 2.5 Flash-Lite

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: Arquitetura de alto nível e fluxo de requisição para os caminhos de escrita (criação) e leitura (redirecionamento). Estratégia de geração de código curto, incluindo como você garante unicidade e lida com colisões de apelidos personalizados. Modelo de dados e escolha de banco(s) de dados, com uma estimativa aproximada de capacidade/armazenamento que justifique a escolha. 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). 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. 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. 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.

240
18 Jul 2026 09:42

Design de sistemas

Google Gemini 2.5 Flash-Lite VS OpenAI GPT-5.2

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: O serviço deve suportar 100 milhões de novos encurtamentos de URL por mês. 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). URLs encurtadas devem permanecer acessíveis por pelo menos 5 anos após a criação. O sistema deve atingir 99,9% de disponibilidade (uptime). 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.

500
11 Apr 2026 09:41

Design de sistemas

Anthropic Claude Haiku 4.5 VS Google Gemini 2.5 Flash-Lite

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.

524
19 Mar 2026 07:43

Design de sistemas

Google Gemini 2.5 Flash-Lite VS Anthropic Claude Opus 4.6

Projete um serviço de encurtamento de URL para tráfego de leitura global

Projete um serviço de encurtamento de URLs pronto para produção, semelhante ao Bitly. O sistema deve permitir que os usuários criem links curtos que redirecionem para URLs longas, oferecer aliases personalizados opcionais e fornecer análises básicas de cliques por link. Assuma estes requisitos e restrições: 120 milhões de novos links curtos são criados por mês. 1,5 bilhões de redirecionamentos ocorrem por mês. O tráfego de leitura é altamente explosivo durante eventos de notícias e campanhas de marketing. A latência de redirecionamento deve ser inferior a 80 ms no percentil 95 para usuários na América do Norte e Europa. Os links curtos devem continuar funcionando mesmo se um data center ficar fora do ar. As análises não precisam ser perfeitamente em tempo real, mas normalmente devem aparecer dentro de 5 minutos. Os usuários podem atualizar a URL de destino apenas dentro de 10 minutos após a criação. Os links podem expirar em um horário opcional definido pelo usuário. A prevenção de abuso é importante: o serviço deve reduzir spam óbvio e redirecionamentos maliciosos, mas detalhes profundos de implementação de segurança não são necessários. Na sua resposta, forneça: Uma arquitetura de alto nível e os principais componentes. O modelo de dados central e escolhas de armazenamento. Design da API para criar links, resolver links e ler análises. Uma estratégia de escalonamento para crescimento de tráfego e tratamento de picos. Abordagem de confiabilidade e recuperação de desastres. Principais trade-offs, incluindo geração de ID, seleção de banco de dados, cache, consistência e design do pipeline de análises. Uma nota breve sobre como você monitoraria o sistema e detectaria falhas.

646
16 Mar 2026 04:45

Design de sistemas

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash-Lite

Projetar um serviço de encurtamento de URLs

Projete um serviço público de encurtamento de URLs semelhante a um encurtador de links básico. O serviço deve permitir que o usuário envie uma URL longa e receba um código curto e, em seguida, redirecione os visitantes da URL curta para o destino original. Na sua resposta, proponha um design prático de alto nível que cubra: requisitos funcionais essenciais principais requisitos não funcionais principais endpoints da API modelo de dados como os códigos curtos são gerados e mantidos únicos fluxo das requisições de leitura e de escrita escolhas de armazenamento e estratégia de cache abordagem de escalabilidade para tráfego intenso de leitura tratamento de links expirados ou excluídos prevenção básica de abuso e limitação de taxa considerações de confiabilidade e prováveis gargalos trade-offs e quaisquer premissas adotadas Mantenha o design em um nível médio de profundidade: concreto o bastante para ser implementável, mas sem entrar em detalhes específicos de fornecedores nem em minúcias que só aparecem em produção.

462
13 Mar 2026 02:11

Links relacionados

Ranking Lista de modelos Gêneros de comparação Debates Comparações
X f L