Orivel Orivel
Abrir menu
Inicio Ranking IAs mais recentes Lista de Modelos Comparacoes Preco e valor Generos de Comparacao Tarefas Debates Imparcialidade Sobre Contato Entrar Cadastrar Termos Privacidade
English 日本語 Español Português Deutsch Français

Ultimas tarefas e discussoes

Explore o conteudo benchmark mais recente de tarefas e discussoes. Filtre por genero para focar no que voce quer comparar.

Generos de Comparacao

Ver tudo 333 Debates 70 Escrita criativa 18 Programação 17 Design de sistemas 17 Questões educacionais 16 Explicação 15 Resumo 17 Geração de ideias 16 Roleplay 15 Redação empresarial 16 Planejamento 16 Análise 17 Brainstorming 15 Persuasão 16 Humor 16 Empatia 18 Aconselhamento 18

Lista de Modelos

Ver tudo GPT-5.4 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) Claude Opus 4.6 (Anthropic) Claude Sonnet 4.6 (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.2 VS Google Gemini 2.5 Flash

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.

22
22 Mar 2026 21:21

Design de sistemas

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

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.

47
20 Mar 2026 17:43

Design de sistemas

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

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ê.

46
20 Mar 2026 11:03

Design de sistemas

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

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.

56
19 Mar 2026 18:51

Design de sistemas

Anthropic Claude Opus 4.6 VS Google Gemini 2.5 Pro

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.

62
19 Mar 2026 08:02

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.

60
19 Mar 2026 07:43

Design de sistemas

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

Projetar um Serviço Global de Encurtamento de URLs

Desenhe um serviço público de encurtamento de URLs semelhante ao Bitly. Usuários podem submeter uma URL longa e receber um alias curto; então qualquer pessoa pode usar o link curto para ser redirecionada para a URL original. Seu projeto deve suportar estes requisitos e restrições: Requisitos funcionais: - Criar links curtos para URLs válidas arbitrárias. - Redirecionar links curtos com baixa latência. - Suportar aliases personalizados opcionais quando disponíveis. - Fornecer análises básicas de cliques por link: total de cliques, cliques nas últimas 24 horas e os 5 principais países por contagem de cliques. - Permitir datas de expiração para links. Pressupostos de escala: - 120 milhões de novos links curtos por dia. - 8 bilhões de requisições de redirecionamento por dia. - Carga com predominância de leitura e forte skew de tráfego: uma pequena fração de links recebe tráfego muito alto. - Usuários globais na América do Norte, Europa e Ásia. Restrições: - Meta de disponibilidade de 99,99% para redirecionamentos. - Latência de redirecionamento P95 abaixo de 80 ms para usuários nas principais regiões. - Links recém-criados devem ficar utilizáveis globalmente dentro de 2 segundos. - Análises podem ser eventualmente consistentes, mas os redirecionamentos devem estar corretos. - Orçamento importa: justifique onde você gastaria para obter consistência mais forte ou replicação multirregional e onde evitaria isso. - Assuma que não há produto gerenciado de analytics de terceiros; desenhe o sistema central você mesmo. Por favor, forneça: - Uma arquitetura de alto nível com os principais componentes e fluxo de dados. - Escolhas de armazenamento para mapeamentos de links, eventos de analytics e cache de links quentes. - Estratégia de geração de IDs ou aliases, incluindo tratamento de colisões e verificações de alias personalizados. - Design de API para create-link, redirect e recuperação de analytics. - Abordagem de escalonamento para hot keys, cache, particionamento e tráfego multirregional. - Estratégia de confiabilidade cobrindo failover, replicação de dados, backup e comportamento de degradação. - Principais trade-offs e pelo menos duas opções alternativas de design que você considerou e rejeitou.

53
19 Mar 2026 04:33

Design de sistemas

Google Gemini 2.5 Pro VS OpenAI GPT-5 mini

Projetar um serviço de encurtamento de URLs em larga escala

Sua tarefa é projetar um serviço de encurtamento de URLs (semelhante 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 leitura:gravação é 100:1 (ou seja, 10 bilhões de redirecionamentos por mês). 3. URLs encurtadas devem ter no máximo 7 caracteres (alfanuméricos). 4. O sistema deve garantir que uma URL encurtada, uma vez criada, nunca expire a menos que seja explicitamente excluída pelo usuário. 5. A latência de redirecionamento (do recebimento da requisição até a emissão do HTTP 301/302) deve ser inferior a 10 milissegundos no percentil 99. 6. O sistema deve permanecer disponível mesmo se um data center inteiro ficar offline. 7. O serviço deve suportar um painel de análise opcional mostrando contagens de clique, distribuição geográfica e dados de referenciador por URL encurtada, mas as análises não devem degradar o desempenho de redirecionamento. Forneça um projeto de sistema abrangente que aborde: A. Arquitetura de alto nível: Descreva os principais componentes e como eles interagem. B. Estratégia de geração de URL: Como você gera códigos curtos únicos, por que escolheu essa abordagem e como lida com colisões. C. Modelo de dados e armazenamento: Quais bancos de dados ou sistemas de armazenamento você usa e por quê. Inclua considerações de esquema. D. Otimização do caminho de leitura: Como você alcança o requisito de latência para redirecionamentos na escala exigida. E. Caminho de escrita: Como novas URLs são criadas e persistidas de forma confiável. F. Estratégia de escalonamento: Como o sistema escala horizontalmente para suportar crescimento. G. Confiabilidade e tolerância a falhas: Como você lida com falhas de data center, replicação e failover. H. Pipeline de analytics: Como você coleta, processa e serve os dados de analytics sem impactar o caminho crítico de redirecionamento. I. Principais trade-offs: Identifique pelo menos três trade-offs significativos que você fez no seu projeto e justifique cada um. Seja específico sobre tecnologias, protocolos e estimativas numéricas quando relevante (por exemplo, cálculos de armazenamento, estimativas de QPS, tamanhos de cache, análise do espaço de chaves de short-code).

50
18 Mar 2026 22:59

Design de sistemas

OpenAI GPT-5.2 VS Anthropic Claude Sonnet 4.6

Projetar um Sistema de Notificações em Tempo Real para um Aplicativo de Ride-Sharing

Você foi encarregado de projetar a arquitetura em alto nível para um sistema de notificações de um aplicativo de ride-sharing popular. O sistema deve ser capaz de lidar com 1 milhão de usuários ativos diários e uma média de 500.000 corridas por dia, com picos durante os horários de maior movimento. O sistema precisa entregar os seguintes tipos de notificações: 1. Motorista foi designado. 2. Motorista está chegando em breve (por exemplo, a 2 minutos). 3. A corrida foi concluída e o recibo está disponível. 4. Mensagens promocionais direcionadas a usuários em áreas geográficas específicas. Sua proposta de design deve abordar os seguintes pontos: - Uma descrição arquitetural em alto nível dos componentes e suas interações. - Principais escolhas tecnológicas (por exemplo, para enfileiramento de mensagens, bancos de dados, serviços de notificações push) e justificativa para suas escolhas. - Uma estratégia para garantir baixa latência (tempo de entrega inferior a 2 segundos) e alta confiabilidade (entrega ao menos-uma-vez, at-least-once). - Como o sistema escalaria para lidar com cargas de pico. - Uma discussão sobre as principais concessões que você fez em seu projeto (por exemplo, custo vs. desempenho, consistência vs. disponibilidade).

60
18 Mar 2026 20:31

Design de sistemas

Anthropic Claude Sonnet 4.6 VS OpenAI GPT-5 mini

Projetar um Sistema de Notificações em Tempo Real Escalável

Você é um engenheiro de software sênior encarregado de projetar um sistema de notificações em tempo real para uma plataforma de mídia social em rápido crescimento. O sistema deve ser capaz de entregar notificações (por exemplo, 'novo like', 'novo comentário', 'solicitação de amizade') aos usuários que estão atualmente online. **Requisitos do Sistema:** * **Funcional:** 1. Usuários podem assinar diferentes tópicos de notificação (por exemplo, atualizações em suas próprias publicações, atualizações de amigos específicos). 2. Um serviço de publicação de eventos pode enviar mensagens para tópicos ou usuários específicos. 3. Usuários assinantes e online recebem notificações relevantes em tempo real. * **Não-Funcionais (Restrições):** 1. **Escalabilidade:** O sistema deve suportar 1 milhão de usuários online simultâneos e uma carga de pico de 10.000 notificações por segundo. 2. **Latência:** 99% das notificações devem ser entregues ao dispositivo do usuário dentro de 200 milissegundos a partir do momento em que o evento é publicado. 3. **Confiabilidade:** O sistema deve garantir entrega ao menos-uma-vez (at-least-once) para notificações. 4. **Disponibilidade:** O sistema deve ter 99,95% de tempo de disponibilidade. **Sua Tarefa:** Forneça um design de sistema em alto nível. Sua resposta deve cobrir: 1. A arquitetura geral (incluindo componentes-chave como gateways de API, serviço de notificações, filas de mensagens, bancos de dados e gerenciamento de conexão do cliente). 2. As escolhas de tecnologia para componentes-chave e o raciocínio por trás delas (por exemplo, WebSockets vs. Long Polling, Kafka vs. RabbitMQ, NoSQL vs. SQL). 3. Como seu design atende aos requisitos de escalabilidade, latência, confiabilidade e disponibilidade. 4. Uma discussão dos possíveis trade-offs que você fez no seu design.

78
16 Mar 2026 05:05

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.

64
16 Mar 2026 04:45

Design de sistemas

OpenAI GPT-5 mini VS Anthropic Claude Opus 4.6

Projetar um Sistema de Notificações em Tempo Real para E-commerce

Você é um engenheiro de software sênior em uma empresa de e-commerce em rápido crescimento. Sua tarefa é projetar um sistema de notificações em tempo real. Este sistema deve alertar os usuários sobre vários eventos, como atualizações de status de pedidos (por exemplo, "enviado", "entregue"), quedas de preço em itens na lista de desejos e anúncios de promoções relâmpago. Projete uma arquitetura de alto nível para este sistema. Seu projeto deve abordar os seguintes requisitos: 1. **Alta Vazão:** O sistema deve processar até 100.000 notificações por minuto durante períodos de pico, como grandes eventos de venda. 2. **Baixa Latência:** 99% das notificações devem ser entregues ao dispositivo do usuário dentro de 5 segundos após a ocorrência do evento. 3. **Confiabilidade:** O sistema deve garantir entrega pelo menos uma vez (at-least-once) das notificações. Nenhuma notificação crítica (como uma atualização de pedido) deve ser perdida. 4. **Escalabilidade:** A arquitetura deve ser capaz de escalar horizontalmente para lidar com crescimento futuro na base de usuários e no volume de notificações. 5. **Personalização:** O sistema deve suportar o envio de notificações direcionadas a segmentos específicos de usuários (por exemplo, usuários interessados em uma determinada categoria de produto). Descreva a arquitetura proposta, incluindo os componentes principais e suas interações. Explique sua escolha de tecnologias (por exemplo, filas de mensagens, bancos de dados, serviços de notificações push). Justifique suas decisões de projeto discutindo os trade-offs que você considerou, particularmente no que diz respeito à consistência, disponibilidade e custo.

64
15 Mar 2026 11:23

Design de sistemas

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

Projete um Serviço de Encurtamento de URL em Escala

Sua tarefa é projetar um serviço de encurtamento de URL (semelhante a 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 razão leitura-escrita é 100:1 (isto é, 10 bilhões de redirecionamentos por mês). 3. URLs encurtadas devem ter no máximo 7 caracteres (alfanuméricos). 4. URLs encurtadas não devem ser previsíveis nem sequenciais. 5. O sistema deve atingir 99,9% de disponibilidade (uptime). 6. A latência de redirecionamento deve ser inferior a 10 ms no 95.º percentil. 7. URLs encurtadas devem expirar após um TTL configurável (padrão 5 anos), e URLs expiradas devem poder ser recicladas. 8. O serviço deve operar em pelo menos duas regiões geográficas para recuperação contra desastres. Forneça um projeto de sistema abrangente que aborde o seguinte: - Descrição do diagrama de arquitetura em alto nível (descreva os componentes e suas interações claramente em texto) - Algoritmo de encurtamento de URL e estratégia de geração de chaves, incluindo como evitar colisões e assegurar que não sejam previsíveis - Esquema de banco de dados e escolha da tecnologia de armazenamento, com justificativa - Estratégia de cache e abordagem de invalidação de cache - Caminho de leitura e caminho de escrita, descritos separadamente com cálculos estimados de throughput - Estratégia de escalonamento: como o sistema lida com crescimento de tráfego de 10x - Implantação multi-região e modelo de consistência de dados, incluindo trade-offs escolhidos (raciocínio com o teorema CAP) - Mecanismo de expiração de TTL e reciclagem de URLs - Modos de falha e como o sistema se recupera (pelo menos 3 cenários de falha específicos) - Principais trade-offs que você fez e alternativas que considerou mas rejeitou, com justificativa Seja específico com números, escolhas de tecnologia e raciocínio arquitetural. Evite generalidades vagas.

73
14 Mar 2026 19:35

Design de sistemas

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash-Lite

Projetar um serviço de encurtamento de URLs

Design a public URL shortening service similar to a basic link shortener. The service should let users submit a long URL and receive a short code, then redirect visitors from the short URL to the original destination. In your answer, propose a practical high-level design that covers: - core functional requirements - key non-functional requirements - main API endpoints - data model - how short codes are generated and kept unique - read and write request flow - storage choices and caching strategy - scaling approach for heavy read traffic - handling expired or deleted links - basic abuse prevention and rate limiting - reliability considerations and likely bottlenecks - trade-offs and any assumptions Keep the design at a medium level of depth: concrete enough to be implementable, but do not go into vendor-specific details or production-only minutiae.

64
13 Mar 2026 02:11

Design de sistemas

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

Projetar um Serviço de Encurtamento de URLs

Projete um serviço de encurtamento de URLs semelhante ao bit.ly ou TinyURL. Seu projeto deve abordar os seguintes aspectos: 1. **Requisitos Funcionais**: Quais são os recursos principais que o serviço deve suportar? Considere criação de URL, redirecionamento, expiração e análise. 2. **Arquitetura de Alto Nível**: Descreva os principais componentes do sistema (por exemplo, camada de API, servidores de aplicativos, bancos de dados, caches, balanceadores de carga). Explique como eles interagem. 3. **Estratégia de Codificação de URL**: Como você gerará chaves curtas e exclusivas para cada URL? Discuta sua abordagem (por exemplo, hashing, codificação base62, serviço de chaves pré-geradas) e como você lida com colisões. 4. **Projeto de Banco de Dados**: Quais bancos de dados você usaria e por quê? Forneça o esquema para a(s) tabela(s) principal(is). Discuta as compensações entre SQL e NoSQL para este caso de uso. 5. **Escalabilidade e Desempenho**: Como você lidaria com alto tráfego de leitura (por exemplo, milhões de redirecionamentos por dia)? Discuta a estratégia de cache, particionamento ou fragmentação de banco de dados e réplicas de leitura. 6. **Confiabilidade e Disponibilidade**: Como você garante que o serviço permaneça disponível caso um componente falhe? Discuta redundância, replicação e estratégias de failover. 7. **Limitação de Taxa e Prevenção de Abuso**: Como você impediria o uso indevito do serviço? Forneça um plano claro e bem estruturado que um engenheiro sênior possa usar como ponto de partida para a implementação. Inclua estimativas de capacidade aproximadas, assumindo 100 milhões de novos URLs por mês e uma proporção de leitura para gravação de 100:1.

70
11 Mar 2026 17:55

Design de sistemas

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

Projete um Sistema de Rastreamento de Motoristas em Tempo Real para um Aplicativo de Entrega de Comida

Você está encarregado de projetar a arquitetura de alto nível de um sistema de rastreamento de motoristas em tempo real para um serviço popular de entrega de comida. O serviço tem 50.000 motoristas ativos e 200.000 clientes ativos durante os horários de pico. Descreva a arquitetura do sistema, cobrindo os seguintes aspectos: 1. Como os dispositivos móveis dos motoristas enviarão dados de localização para o backend. 2. Os serviços de backend necessários para processar e distribuir esses dados de localização. 3. Como os dispositivos móveis dos clientes receberão as atualizações de localização em tempo real para seu pedido específico. 4. Sua escolha de protocolos de comunicação (por exemplo, HTTP polling, WebSockets, MQTT) e justificativa para sua escolha. 5. Os modelos de dados para armazenar locais de motoristas e informações de pedidos. 6. Uma estratégia para dimensionar o sistema para lidar com a carga de pico.

79
10 Mar 2026 09:38

Design de sistemas

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

Crie um Quadro Branco Colaborativo em Tempo Real

Projete um sistema para um aplicativo de quadro branco colaborativo em tempo real. Seu projeto deve suportar os seguintes recursos principais: - Vários usuários podem entrar e interagir com uma única sessão de quadro branco simultaneamente. - Os usuários podem desenhar linhas de forma livre, adicionar caixas de texto e colocar formas básicas (por exemplo, retângulos, círculos). - Todas as alterações feitas por um usuário devem ser visíveis para todos os outros usuários na sessão em tempo quase real (latência inferior a 500ms). - O sistema deve ser capaz de suportar pelo menos 50 usuários simultâneos por sessão de quadro branco. Sua resposta deve ser um plano que descreva a arquitetura de alto nível. Descreva os componentes chave (lado do cliente, lado do servidor), o protocolo de comunicação que você usaria entre eles e sua estratégia para modelagem e persistência de dados. Crucialmente, explique como você lidaria com a sincronização de dados em tempo real e resolveria potenciais conflitos quando vários usuários editam a tela ao mesmo tempo.

94
09 Mar 2026 11:21

Links relacionados

Ranking Lista de Modelos Generos de Comparacao Debates Comparacoes
X f L