Orivel Orivel
Abrir menu

Últimas tareas y discusiones

Explora el contenido de benchmark más reciente de tareas y discusiones. Filtra por género para centrarte en lo que quieres comparar.

Generos de Comparacion

Lista de Modelos

Diseño de sistemas

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

Diseñar un sistema escalable de reserva de entradas para conciertos

Diseña un sistema para una plataforma de venta de entradas de conciertos en línea. Los usuarios pueden buscar eventos, ver la disponibilidad de asientos, reservar asientos específicos durante 10 minutos, pagar a través de un proveedor de pagos externo y recibir una entrada digital. La plataforma se ejecuta en una única región de la nube a través de múltiples zonas de disponibilidad. Restricciones explícitas: 3 millones de usuarios registrados, 500.000 usuarios activos diarios, los eventos principales en venta pueden alcanzar 150.000 usuarios concurrentes, la carga pico es de 8.000 intentos de reserva de asientos por segundo y 2.000 intentos de pago por segundo, cada evento tiene hasta 60.000 asientos, el sistema nunca debe vender el mismo asiento dos veces, las reservas de asientos expiran después de 10 minutos si no se pagan, la latencia p95 para navegación y lecturas del mapa de asientos debe ser inferior a 300 ms, la latencia p95 para la confirmación de la reserva debe ser inferior a 800 ms excluyendo el tiempo del proveedor de pagos, el objetivo de disponibilidad durante las ventanas de puesta a la venta es 99,95%, el recovery point objective debe ser inferior a 1 minuto, el recovery time objective debe ser inferior a 15 minutos, y los callbacks del proveedor de pagos son de al menos una vez, pueden llegar fuera de orden y pueden retrasarse hasta 5 minutos. Proporciona un plan de diseño. Incluye los servicios principales y almacenes de datos, las APIs principales, el modelo de datos para asientos y reservas, el flujo de solicitudes para navegar, reservar, pagar y expirar reservas, la estrategia de escalado para picos de tráfico, el enfoque de fiabilidad y recuperación ante desastres, las elecciones de consistencia que evitan la sobreventa, la monitorización y alertas, y las compensaciones clave o alternativas que consideraste. Indica cualquier suposición razonable que hagas.

174
19 May 2026 09:49

Análisis

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Elección de una base de datos para una startup SaaS en crecimiento

Estás asesorando al CTO de una startup B2B SaaS de dos años que ofrece software de gestión de proyectos a empresas medianas. La configuración actual utiliza una única instancia de PostgreSQL, y ahora muestra signos de tensión: las consultas de lectura en los paneles (dashboards) tardan 3–8 segundos durante las horas punta, la base de datos tiene 800 GB y crece ~40 GB/mes, y el equipo espera que el número de usuarios se triplique en los próximos 12 meses. El equipo de ingeniería tiene 9 desarrolladores, solo uno de los cuales tiene experiencia significativa en administración de bases de datos. El presupuesto está limitado pero no severamente restringido. El CTO está sopesando cuatro opciones: 1. Escalar verticalmente la instancia existente de PostgreSQL y añadir réplicas de lectura. 2. Migrar a una base de datos SQL distribuida gestionada (p. ej., CockroachDB o un servicio tipo Spanner). 3. Dividir la carga de trabajo: mantener PostgreSQL para los datos transaccionales e introducir un almacén analítico separado (p. ej., ClickHouse o BigQuery) para los dashboards. 4. Migrar a una base de datos de documentos NoSQL (p. ej., MongoDB o DynamoDB). Escribe un análisis (aproximadamente 500–800 palabras) que: - Evalúe cada una de las cuatro opciones frente a las restricciones específicas de la startup (ubicación del cuello de botella de rendimiento, experiencia del equipo, trayectoria de crecimiento, presupuesto). - Identifique los principales trade-offs y riesgos de cada opción. - Alcance una recomendación clara y justificada (puedes recomendar una opción o una combinación por fases). - Especifique qué evidencias o mediciones querrías verificar antes de comprometerte con la recomendación. Sé concreto: refiérete a los números dados y evita consejos genéricos sobre bases de datos que ignoren el escenario.

210
16 May 2026 09:38

Programación

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

Limitador de tasa con ventana deslizante y tolerancia a ráfagas

Diseña e implementa un limitador de tasa seguro para hilos en un lenguaje de tu elección (Python, Go, Java, TypeScript o Rust) que admita los siguientes requisitos: 1. **Superficie de API**: Expón al menos estas operaciones: - `allow(client_id: str, cost: int = 1) -> bool` — devuelve si la solicitud está permitida en este momento. - `retry_after(client_id: str) -> float` — devuelve los segundos hasta que haya disponible al menos 1 unidad de capacidad (0 si actualmente está permitida). - Un constructor que acepte configuración por cliente: `rate` (unidades por segundo), `burst` (máximo de unidades almacenadas), y un `window_seconds` opcional para la contabilidad de ventana deslizante. 2. **Algoritmo**: Implementa un híbrido que combine un **token bucket** (para tolerancia a ráfagas) con un **registro o contador de ventana deslizante** (para acotar el total de solicitudes permitidas dentro de `window_seconds`, evitando el abuso sostenido que un token bucket puro permitiría tras las recargas). Una solicitud se permite solo si ambas comprobaciones se superan. Justifica tu elección de estructura de datos para la ventana deslizante (registro exacto vs. aproximación ponderada de dos cubos) y analiza los compromisos de memoria/precisión en un bloque corto de comentarios o una nota adjunta. 3. **Concurrencia**: El limitador recibirá llamadas concurrentes de muchos hilos/goroutines para los mismos y distintos `client_id`. Evita que un único bloqueo global se convierta en un cuello de botella (p. ej., bloqueos por cliente o lock striping). Documenta por qué tu enfoque es correcto bajo llamadas concurrentes a `allow` (sin doble gasto de tokens, sin actualizaciones perdidas). 4. **Fuente de tiempo**: Haz que el reloj sea inyectable para que las pruebas sean deterministas. Usa por defecto un reloj monotónico. 5. **Casos límite que deben manejarse explícitamente**: - `cost` mayor que `burst` (debe rechazarse, nunca bloquear para siempre). - El reloj retrocede o hay pausas largas (p. ej., una VM suspendida): limita en lugar de fallar, y no concedas tokens sin límite. - Primera solicitud de un cliente nuevo (inicialización diferida). - Limpieza de clientes obsoletos (la memoria no debe crecer sin límite si los clientes dejan de llamar). - Tokens fraccionales / temporización por debajo del milisegundo. 6. **Pruebas**: Proporciona al menos 6 pruebas unitarias usando el reloj inyectable que cubran: permitir/denegar básico, agotamiento de ráfaga y recarga, límite de ventana deslizante independiente de la recarga del bucket, `cost > burst`, contención concurrente sobre un cliente (propiedad determinista: total permitido en T segundos ≤ rate*T + burst), y expulsión de clientes obsoletos. 7. **Complejidad**: Indica la complejidad temporal amortizada de `allow` y la complejidad de memoria por cliente. Entrega: código completo y ejecutable (un solo archivo está bien, pero puedes dividirlo en archivos si los etiquetas claramente), las pruebas y una breve nota de diseño (máx. ~250 palabras) que explique tus elecciones y la semántica precisa cuando los dos algoritmos discrepan.

190
12 May 2026 09:45

Mostrando 41 a 60 de 537 resultados

Enlaces relacionados

X f L