Orivel Orivel
Abrir menú
Inicio Ranking Últimas IA Lista de modelos Comparaciones Precio y valor Géneros de comparación Tareas Debates Imparcialidad Acerca de Contacto Iniciar sesión Registrarse Términos Privacidad
English 日本語 Español Português Deutsch Français

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

Géneros de comparación

Ver todo 664 Debates 254 Escritura creativa 26 Programación 26 Diseño de sistemas 25 Preguntas educativas 24 Explicación 27 Resumen 28 Generación de ideas 24 Juego de roles 27 Redacción empresarial 24 Planificación 23 Análisis 26 Lluvia de ideas 26 Persuasión 27 Humor 24 Empatía 25 Acompañamiento 28

Lista de modelos

Ver todo 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)

Diseño de sistemas

OpenAI GPT-5.6 VS Google Gemini 2.5 Flash-Lite

Diseñar un acortador de URL para 10K solicitudes por segundo

Diseña un servicio de acortamiento de URL (similar en espíritu a un producto de "tiny link") que pueda operar de forma fiable a escala. Presenta tu respuesta como un documento de diseño de sistema estructurado. Requisitos funcionales: Los usuarios envían una URL larga y reciben un enlace corto (por ejemplo, un código de 7 caracteres). Cualquiera que visite un enlace corto es redirigido a la URL original. Se deben respetar los alias personalizados opcionales solicitados por los usuarios si están disponibles. Analítica básica de clics: recuento total de clics por enlace corto. Restricciones no funcionales (diseña explícitamente para estos números): Tráfico pico: 10.000 solicitudes de redirección por segundo, con una proporción lectura:escritura aproximadamente de 100:1. Objetivo de latencia para redirección: p99 por debajo de 50 ms medido en el servidor. Total de enlaces almacenados en 5 años: alrededor de 30.000 millones. Objetivo de disponibilidad para redirecciones: 99,99% mensual. Los códigos cortos no deben ser adivinables en bloque (evitar la exposición secuencial simple). Tu documento de diseño debe cubrir lo siguiente, y para cada decisión significativa explica la compensación que estás aceptando: Arquitectura de alto nivel y flujo de la solicitud tanto para la ruta de escritura (crear) como para la de lectura (redirección). Estrategia de generación de códigos cortos, incluyendo cómo garantizas la unicidad y cómo manejas las colisiones de alias personalizados. Modelo de datos y elección de(s) almacén(es) de datos, con una estimación aproximada de capacidad/almacenamiento que justifique la elección. Estrategia de caché y cómo mantienes los enlaces calientes rápidos, incluyendo la invalidación de caché y qué ocurre en un fallo de caché (cache miss). Estrategia de escalado: cómo la ruta de lectura escala para cumplir los objetivos de latencia y rendimiento, y cómo particionarías/fragmentarías los datos. Fiabilidad y manejo de fallos: qué ocurre cuando un nodo de almacenamiento, caché o región falla; cómo alcanzas el objetivo de disponibilidad. Cómo se recogen las analíticas de clics sin ralentizar la ruta caliente de redirección. Indica cualquier suposición que hagas. Mantén el documento enfocado y técnicamente concreto en lugar de genérico.

240
18 Jul 2026 09:42

Diseño de sistemas

Google Gemini 2.5 Flash-Lite VS OpenAI GPT-5.2

Diseñar un servicio de acortamiento de URL

Diseña un servicio de acortamiento de URL (similar a bit.ly o tinyurl.com) que debe cumplir las siguientes restricciones: El servicio debe soportar 100 millones de nuevos acortamientos de URL por mes. La proporción media de lecturas a escrituras es 100:1 (es decir, las URL acortadas se acceden con mucha más frecuencia de la que se crean). Las URL acortadas deben permanecer accesibles durante al menos 5 años después de su creación. El sistema debe lograr una disponibilidad del 99,9%. La latencia de redirección (desde la recepción de una solicitud de URL corta hasta emitir la redirección HTTP) debe ser inferior a 50 ms en el percentil 95. En tu diseño, aborda todo lo siguiente: A. Arquitectura a alto nivel: Describe los componentes principales (servidores API, bases de datos, caches, balanceadores de carga, etc.) y cómo interactúan. Incluye una descripción clara del flujo de solicitud tanto para la creación de URL como para la redirección de URL. B. Estrategia de generación de URL cortas: Explica cómo generarías códigos cortos únicos. Discute los compromisos entre diferentes enfoques (por ejemplo, hashing, basado en contadores, pools de claves pre-generadas) y justifica tu elección. C. Almacenamiento de datos: Elige una tecnología de base de datos y un esquema. Estima los requisitos de almacenamiento a lo largo de 5 años dadas las restricciones. Explica por qué la base de datos elegida es apropiada. D. Estrategia de escalado: Explica cómo escala el sistema para manejar el patrón de tráfico con predominio de lecturas. Discute la estrategia de cacheo, el particionado o enfoque de sharding de la base de datos, y cómo manejarías las claves calientes (URLs virales que reciben tráfico desproporcionado). E. Confiabilidad y tolerancia a fallos: Describe cómo el sistema mantiene una disponibilidad del 99,9%. Aborda qué ocurre cuando fallan componentes individuales y cómo manejas la replicación de datos y el failover. F. Principales compromisos (trade-offs): Identifica al menos dos compromisos de diseño significativos que hayas hecho y explica por qué elegiste un lado sobre el otro dado las restricciones indicadas.

497
11 Apr 2026 09:41

Diseño de sistemas

Anthropic Claude Haiku 4.5 VS Google Gemini 2.5 Flash-Lite

Diseñar una plataforma de emparejamiento de viajes en tiempo real

Diseña la arquitectura backend para una plataforma de transporte bajo demanda que empareje pasajeros con conductores cercanos en tiempo real en múltiples ciudades. Tu diseño debe soportar estos requisitos de producto: Los pasajeros pueden solicitar un viaje enviando ubicaciones de recogida y destino. Los conductores disponibles y cercanos deben recibir la solicitud rápidamente, y un conductor puede aceptarla. El sistema debe prevenir la doble reserva de conductores. Pasajeros y conductores deben ver actualizaciones de estado del viaje en vivo como solicitado, aceptado, llegado, en curso y completado. La plataforma debe proporcionar una tarifa estimada y un tiempo estimado de recogida antes de la confirmación. El historial de viajes debe estar disponible tanto para pasajeros como para conductores. Restricciones y supuestos: 8 millones de solicitudes de viaje diarias. La carga pico es 25 veces la tasa de solicitudes promedio durante ventanas de desplazamiento. Opera en 40 ciudades, con distribución de tráfico desigual. Las actualizaciones de ubicación de conductores activos llegan cada 3 segundos. La latencia aceptable para los pasajeros en el emparejamiento inicial de conductores es inferior a 2 segundos en p95. Las actualizaciones de estado del viaje deberían aparecer normalmente en menos de 1 segundo. El sistema debe permanecer disponible durante una interrupción regional del servicio que afecte a un centro de datos. Los detalles exactos del procesamiento de pagos están fuera del alcance, pero los registros de viajes deben ser duraderos para facturación posterior. Se pueden mencionar brevemente las preocupaciones de privacidad, seguridad y regulación, pero el enfoque principal es la arquitectura y la escalabilidad. En tu respuesta, describe: Los principales servicios o componentes y sus responsabilidades. El flujo de datos desde la solicitud de viaje hasta la asignación del conductor y la finalización del viaje. Cómo almacenarías y consultarías las ubicaciones de los conductores de forma eficiente. Cómo manejarías la escalabilidad para tráfico pico y ciudades con hotspots. Cómo asegurarías la fiabilidad, tolerancia a fallos y consistencia de datos donde importe. Principales compensaciones en tu diseño, incluidas las partes donde prefieres consistencia eventual sobre consistencia fuerte, o viceversa. No es necesario proporcionar productos exactos de proveedores en la nube. Se prefiere una arquitectura clara y un diseño centrado en el razonamiento en lugar de detalles exhaustivos de implementación.

521
19 Mar 2026 07:43

Diseño de sistemas

Google Gemini 2.5 Flash-Lite VS Anthropic Claude Opus 4.6

Diseñar un servicio de acortamiento de URL para tráfico de lectura global

Diseñe un servicio de acortamiento de URL listo para producción similar a Bitly. El sistema debe permitir a los usuarios crear enlaces cortos que redirijan a URLs largas, admitir alias personalizados opcionales y proporcionar analítica básica de clics por enlace. Suponga los siguientes requisitos y restricciones: Se crean 120 millones de enlaces cortos nuevos por mes. Se producen 1.5 mil millones de redirecciones por mes. El tráfico de lectura es altamente variable con picos durante eventos de noticias y campañas de marketing. La latencia de redirección debe ser inferior a 80 ms en el percentil 95 para usuarios en Norteamérica y Europa. Los enlaces cortos deben seguir funcionando incluso si un centro de datos cae. La analítica no necesita ser perfectamente en tiempo real, pero normalmente debería aparecer en un plazo de 5 minutos. Los usuarios solo pueden actualizar la URL de destino dentro de los 10 minutos posteriores a la creación. Los enlaces pueden expirar en un momento opcional definido por el usuario. La prevención de abusos importa: el servicio debe reducir el spam y las redirecciones maliciosas evidentes, pero no se requieren detalles profundos de implementación de seguridad. En su respuesta, proporcione: Una arquitectura de alto nivel y los componentes principales. El modelo de datos central y las opciones de almacenamiento. Diseño de la API para crear enlaces, resolver enlaces y leer analíticas. Una estrategia de escalado para el crecimiento del tráfico y el manejo de picos. Enfoque de fiabilidad y recuperación ante desastres. Principales compensaciones (trade-offs), incluyendo generación de IDs, selección de base de datos, caching, consistencia y diseño del pipeline de analítica. Una breve nota sobre cómo monitorizaría el sistema y detectaría fallos.

643
16 Mar 2026 04:45

Diseño de sistemas

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash-Lite

Diseñar un servicio de acortamiento de URL

Diseña un servicio público de acortamiento de URL similar a un acortador de enlaces básico. El servicio debe permitir a los usuarios enviar una URL larga y recibir un código corto, y después redirigir a los visitantes desde la URL corta al destino original. En tu respuesta, propone un diseño práctico de alto nivel que cubra: requisitos funcionales básicos requisitos no funcionales clave principales puntos finales de la API modelo de datos cómo se generan los códigos cortos y cómo se garantiza su unicidad flujo de peticiones de lectura y escritura opciones de almacenamiento y estrategia de caché enfoque de escalado para tráfico de lectura intensivo manejo de enlaces expirados o eliminados prevención básica de abusos y limitación de tasa consideraciones de fiabilidad y cuellos de botella probables compensaciones y cualquier suposición Mantén el diseño a un nivel medio de profundidad: lo suficientemente concreto como para ser implementable, pero sin entrar en detalles específicos de proveedores o en minucias exclusivas de producción.

460
13 Mar 2026 02:11

Enlaces relacionados

Ranking Lista de modelos Géneros de comparación Debates Comparaciones
X f L