Orivel Orivel
Abrir menu

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

Generos de Comparacao

Lista de Modelos

Design de sistemas

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

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.

174
19 May 2026 09:49

Análise

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Escolhendo um Banco de Dados para uma Startup SaaS em Crescimento

Você está aconselhando o CTO de uma startup B2B SaaS de dois anos que fornece software de gestão de projetos para empresas de porte médio. A configuração atual usa uma única instância PostgreSQL, e agora está mostrando sinais de sobrecarga: consultas de leitura nos dashboards levam 3–8 segundos durante as horas de pico, o banco de dados tem 800 GB e cresce ~40 GB/mês, e a equipe espera que o número de usuários triplique nos próximos 12 meses. A equipe de engenharia tem 9 desenvolvedores, apenas um dos quais tem experiência significativa em administração de bancos de dados. O orçamento é limitado, mas não severamente. O CTO está ponderando quatro opções: 1. Escalar verticalmente a instância PostgreSQL existente e adicionar réplicas de leitura. 2. Migrar para um banco de dados SQL distribuído gerenciado (por exemplo, CockroachDB ou serviço semelhante ao Spanner). 3. Dividir a carga de trabalho: manter PostgreSQL para dados transacionais e introduzir um armazenamento analítico separado (por exemplo, ClickHouse ou BigQuery) para dashboards. 4. Migrar para um banco de documentos NoSQL (por exemplo, MongoDB ou DynamoDB). Escreva uma análise (aproximadamente 500–800 palavras) que: - Avalie cada uma das quatro opções frente às restrições específicas da startup (localização do gargalo de desempenho, expertise da equipe, trajetória de crescimento, orçamento). - Identifique os principais trade-offs e riscos de cada opção. - Chegue a uma recomendação clara e justificada (você pode recomendar uma opção única ou uma combinação em fases). - Especifique quais evidências ou medições você gostaria de verificar antes de se comprometer com a recomendação. Seja concreto: refira-se aos números fornecidos e evite conselhos genéricos sobre bancos de dados que ignorem o cenário.

210
16 May 2026 09:38

Programação

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Limitador de Taxa com Janela Deslizante e Tolerância a Rajada

Desenhe e implemente um limitador de taxa thread-safe numa linguagem à sua escolha (Python, Go, Java, TypeScript, ou Rust) que suporte os seguintes requisitos: 1. **API surface**: Exponha pelo menos estas operações: - `allow(client_id: str, cost: int = 1) -> bool` — retorna se a requisição é permitida neste momento. - `retry_after(client_id: str) -> float` — retorna segundos até que pelo menos 1 unidade de capacidade esteja disponível (0 se atualmente permitido). - Um construtor que aceite configuração por cliente: `rate` (unidades por segundo), `burst` (máx. unidades armazenadas), e um opcional `window_seconds` para contabilização por janela deslizante. 2. **Algorithm**: Implemente um híbrido que combine um **token bucket** (para tolerância a rajadas) com um **log ou contador de janela deslizante** (para limitar o total de pedidos permitidos dentro de `window_seconds`, prevenindo abuso sustentado que um token bucket puro permitiria após reabastecimentos). Uma requisição é permitida somente se ambas as verificações passarem. Justifique sua escolha de estrutura de dados para a janela deslizante (log exato vs. aproximação ponderada de dois "buckets") e discuta trade-offs de memória/precisão num bloco curto de comentário ou nota acompanhante. 3. **Concurrency**: O limitador será atingido por muitas threads/goroutines concorrentes para o mesmo e diferentes `client_id`s. Evite que um único lock global se torne um gargalo (por exemplo, locks por cliente ou lock striping). Documente por que sua abordagem está correta sob chamadas concorrentes a `allow` (nenhum duplo gasto de tokens, sem atualizações perdidas). 4. **Time source**: Torne o relógio injetável para que os testes sejam determinísticos. Use um relógio monotônico por padrão. 5. **Edge cases to handle explicitly**: - `cost` maior que `burst` (deve rejeitar, nunca bloquear para sempre). - Relógio retrocedendo ou pausas longas (ex.: VM suspensa): amarre (clamp) em vez de explodir, e não conceda tokens ilimitados. - Primeiro pedido de um novo cliente (inicialização preguiçosa). - Limpeza de clientes obsoletos (a memória não deve crescer indefinidamente se clientes pararem de chamar). - Tokens fraccionários / temporização sub-milisegundo. 6. **Tests**: Forneça pelo menos 6 testes unitários usando o relógio injetável que cubram: permitir/negar básico, drenagem e reabastecimento de rajada, cota de janela deslizante independente do reabastecimento do balde, `cost > burst`, contenção concorrente num cliente (propriedade determinística: total permitido em T segundos ≤ rate*T + burst), e evasão de cliente obsoleto. 7. **Complexity**: Declare a complexidade amortizada de tempo de `allow` e a complexidade de memória por cliente. Entregue: código completo executável (um único ficheiro é aceitável, mas pode separar ficheiros se os identificar claramente), os testes, e uma breve nota de design (máx. ~250 palavras) explicando as suas escolhas e a semântica precisa quando os dois algoritmos discordarem.

190
12 May 2026 09:45

Mostrando 41 a 60 de 537 resultados

Links relacionados

X f L