Diseño de sistemas
Explora como rinden los modelos de IA en Diseño de sistemas. Compara clasificaciones, criterios de evaluacion y benchmarks recientes.
Resumen del genero
Compara arquitectura, razonamiento de compromisos y calidad de diseño de sistemas.
En este genero, las capacidades que mas se intentan medir son Calidad de la arquitectura, Integridad, Analisis de compromisos.
A diferencia de coding, este genero pesa mas arquitectura, escala, fiabilidad y trade-offs que los detalles de implementacion ejecutable.
Una puntuacion alta aqui no significa que el modelo vaya a escribir el mejor codigo funcional ni la explicacion mas sencilla.
Para que sirve un modelo fuerte en este genero
propuestas de arquitectura, diseno de servicios y conversaciones sobre escalabilidad.
Lo que este genero por si solo no alcanza a mostrar
calidad de implementacion de bajo nivel, correccion exacta o escritura para publico no tecnico.
Ranking de modelos fuertes en este genero
Este ranking se ordena por la puntuacion media solo dentro de este genero.
Ultima actualizacion: 22 Mar 2026 21:21
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
Tasa de victoria
Puntuacion media
| Modelos clasificados | Detalle | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 | OpenAI |
100%
|
90
|
3 | 3 | Ver la evaluacion y la puntuacion de GPT-5.2 |
| #2 | GPT-5.4 | OpenAI |
100%
|
89
|
3 | 3 | Ver la evaluacion y la puntuacion de GPT-5.4 |
| #3 | Claude Opus 4.6 | Anthropic |
100%
|
87
|
3 | 3 | Ver la evaluacion y la puntuacion de Claude Opus 4.6 |
| #4 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Ver la evaluacion y la puntuacion de GPT-5 mini |
| #5 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Ver la evaluacion y la puntuacion de Claude Sonnet 4.6 |
| #6 | Claude Haiku 4.5 | Anthropic |
50%
|
84
|
2 | 4 | Ver la evaluacion y la puntuacion de Claude Haiku 4.5 |
| #7 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Ver la evaluacion y la puntuacion de Gemini 2.5 Pro | |
| #8 | Gemini 2.5 Flash |
0%
|
74
|
0 | 5 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash-Lite |
Que se evalua en Diseño de sistemas
Criterios y pesos usados para este ranking por genero.
Calidad de la arquitectura
30.0%
Este criterio se incluye para comprobar Calidad de la arquitectura en la respuesta. Tiene mas peso porque este aspecto cambia mucho el resultado global del genero.
Integridad
20.0%
Este criterio se incluye para comprobar Integridad en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Analisis de compromisos
20.0%
Este criterio se incluye para comprobar Analisis de compromisos en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Escalabilidad y fiabilidad
20.0%
Este criterio se incluye para comprobar Escalabilidad y fiabilidad en la respuesta. Tiene un peso importante porque afecta la calidad de forma visible, aunque no sea lo unico que importa.
Claridad
10.0%
Este criterio se incluye para comprobar Claridad en la respuesta. Tiene menos peso porque acompana el objetivo principal, pero no define por si solo este genero.
Tareas recientes
Diseño de sistemas
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 manejar las siguientes restricciones: 1. El servicio debe soportar 100 millones de nuevos acortamientos de URL por mes. 2. La proporción de solicitudes de lectura (redirección) a solicitudes de escritura (acortamiento) es de 100:1. 3. Las URLs acortadas deben ser lo más cortas posible pero deben soportar el volumen esperado durante al menos 10 años. 4. El sistema debe alcanzar una disponibilidad de tiempo de actividad del 99,9%. 5. La latencia de redirección debe ser inferior a 50 ms en el percentil 95. 6. El servicio debe manejar una degradación gradual si un centro de datos se queda sin servicio. En tu diseño, aborda cada una de las siguientes áreas: A) Diseño de la API: Define los endpoints clave de la API y sus contratos. B) Modelo de datos y almacenamiento: Elige una solución de almacenamiento, justifica tu elección, explica tu esquema y estima el almacenamiento total necesario durante 10 años. C) Generación de URL corta: Describe tu algoritmo para generar códigos cortos. Explica cómo evitas colisiones y qué conjunto de caracteres y longitud elegiste, con una justificación matemática de por qué el espacio de claves es suficiente. D) Escalado y rendimiento: Explica cómo escalarías lecturas y escrituras de forma independiente. Describe tu estrategia de caché, incluida la política de expulsión y la tasa de aciertos esperada. Explica cómo cumples con el requisito de latencia de 50 ms p95. E) Confiabilidad y tolerancia a fallos: Describe cómo maneja el sistema las caídas de centros de datos, la estrategia de replicación de datos y qué compensaciones haces entre consistencia y disponibilidad (referencia el teorema CAP). F) Discusión de compensaciones: Identifica al menos dos compromisos de diseño significativos que hayas tomado y explica por qué elegiste una opción sobre la otra, incluyendo qué sacrificarías y qué ganarías. Presenta tu respuesta como un plan estructurado con secciones claras correspondientes a A hasta F.
Diseño de sistemas
Diseñar un servicio de acortamiento de URLs
Diseña un servicio de acortamiento de URLs (similar a bit.ly o tinyurl.com) que deba manejar las siguientes restricciones: 1. El servicio debe soportar 100 millones de nuevos acortamientos de URL por mes. 2. La proporción lectura-escritura es 100:1 (es decir, por cada URL creada, se accede a ella 100 veces en promedio). 3. Las URLs acortadas deben permanecer accesibles durante al menos 5 años. 4. El sistema debe lograr un 99.9% de tiempo de actividad (uptime). 5. La latencia de redirección (desde recibir una solicitud de URL corta hasta emitir la redirección HTTP) debe ser inferior a 50 ms en el percentil 95. Tu diseño debe abordar todas las siguientes áreas: A. **Short URL Generation Strategy**: ¿Cómo generarás códigos cortos únicos y compactos? Discute el esquema de codificación, la longitud esperada de las URLs y cómo manejas colisiones o el agotamiento del espacio de claves. B. **Data Storage**: ¿Qué base(s) de datos usarás y por qué? Estima el almacenamiento total necesario durante 5 años. Explica el diseño de tu esquema y cualquier estrategia de particionado o sharding. C. **Read Path Architecture**: ¿Cómo atenderás las solicitudes de redirección a escala para cumplir los requisitos de latencia y rendimiento? Discute las capas de caché, el uso de CDN y cualquier estrategia de replicación. D. **Write Path Architecture**: ¿Cómo manejarás la ingestión de 100M de nuevas URLs por mes de forma fiable? Discute cualquier cola, limitación de tasa (rate limiting) o consideraciones de consistencia. E. **Reliability and Fault Tolerance**: ¿Cómo maneja tu sistema fallos de nodos, cortes de centros de datos o invalidación de caché? ¿Cuál es tu estrategia de respaldo y recuperación? F. **Key Trade-offs**: Identifica al menos dos compensaciones significativas en tu diseño (por ejemplo, consistencia frente a disponibilidad, coste de almacenamiento frente a rendimiento de lectura, simplicidad frente a escalabilidad) y explica por qué escogiste el lado que elegiste. Presenta tu respuesta como un documento de diseño estructurado con secciones claras correspondientes a A a F anteriores.
Diseño de sistemas
Diseñar un servicio global de acortamiento de URL
Diseña un servicio público de acortamiento de URL similar a Bitly. Los usuarios pueden enviar una URL larga y recibir un alias corto; al visitar el enlace corto, debe redirigirse rápidamente a la URL original. El sistema debe soportar alias personalizados, fechas de expiración opcionales, analítica básica de clics y mitigación de abuso para enlaces maliciosos. Requisitos y restricciones: - Requisitos funcionales: - Crear URLs cortas para URLs largas. - Redirigir URLs cortas a las URLs originales. - Soportar alias personalizados cuando estén disponibles. - Soportar tiempo de expiración opcional por enlace. - Registrar eventos de clic para analítica. - Permitir que los usuarios desactiven un enlace manualmente. - Supuestos de escala: - 120 millones de nuevas URLs cortas por mes. - 1.5 mil millones de redirecciones por día. - El tráfico de redirección está distribuido globalmente y es de lectura intensiva. - Los datos analíticos deben ser consultables en un plazo de 15 minutos. - Objetivos de rendimiento: - Latencia de redirección p95 por debajo de 80 ms para la mayoría de las regiones. - Creación de enlaces cortos p95 por debajo de 300 ms. - 99.99% de disponibilidad para redirecciones. - Datos y retención: - Los enlaces pueden vivir indefinidamente a menos que expiren o sean deshabilitados. - Los eventos de clic en bruto pueden conservarse durante 90 días; la analítica agregada durante 2 años. - Restricciones operativas: - Usar infraestructura en la nube de uso general; no asumir que un producto gestionado exótico lo resuelve todo. - El presupuesto importa: justifique cualquier elección de replicación, caché y almacenamiento. - Los códigos cortos deben ser compactos y razonablemente difíciles de adivinar a gran escala, pero no se requiere secreto perfecto. En su respuesta, proporcione: 1. Una arquitectura de alto nivel con componentes principales y flujo de datos. 2. Opciones de almacenamiento para metadata de enlaces, ruta de redirección y eventos analíticos, con su justificación. 3. Una estrategia de generación de códigos cortos, incluyendo cómo evitar colisiones y cómo manejar alias personalizados. 4. Un plan de escalado para tráfico global, incluyendo caché, particionado/sharding y consideraciones multinube/multiregión. 5. Un plan de confiabilidad que cubra fallos, claves calientes, recuperación ante desastres y comportamiento en modo degradado. 6. APIs clave y modelos de datos principales. 7. Mitigación de abuso y consideraciones de seguridad. 8. Los principales trade-offs que realizó y por qué.
Diseño de sistemas
Diseñar un servicio global de acortamiento de URL
Diseñe un servicio de acortamiento de URL disponible globalmente similar a Bitly. El servicio debe permitir a los usuarios crear enlaces cortos que redirijan a URL largas, admitir alias personalizados para usuarios de pago, rastrear analíticas de clics y permitir que los enlaces expiren en un momento especificado. Requisitos: - Manejar 120 millones de nuevos enlaces cortos por día. - Manejar 4 mil millones de redireccionamientos por día. - El tráfico pico puede alcanzar 3 veces el promedio diario. - Objetivo de latencia de redirección: p95 por debajo de 80 ms para usuarios en Norteamérica, Europa y Asia. - Objetivo de latencia de creación de enlaces cortos: p95 por debajo de 300 ms. - Objetivo de disponibilidad del servicio: 99.99% para redireccionamientos. - Los datos de analítica pueden ser eventualmente consistentes dentro de 5 minutos. - Los alias personalizados deben ser únicos a nivel global. - Los enlaces caducados o eliminados deben dejar de redirigir rápidamente. - El sistema debe tolerar fallas regionales sin una interrupción total del servicio. Suposiciones que puede usar: - La longitud promedio de la URL larga es de 500 bytes. - Los eventos de analítica incluyen marca de tiempo, ID del enlace, país, tipo de dispositivo y dominio referidor. - El tráfico de lectura es mucho mayor que el de escritura. - Puede elegir tecnologías SQL, NoSQL, caché, streaming, CDN y mensajería según sea necesario, pero justifíquelas. En su respuesta, proporcione: 1. Una arquitectura de alto nivel con los componentes principales y los flujos de solicitud. 2. Modelo de datos y elecciones de almacenamiento para enlaces, alias y analíticas. 3. Una estrategia de escalado para tráfico mayoritariamente de lectura, incluyendo caché y enrutamiento regional. 4. Una estrategia de fiabilidad que cubra conmutación por error, decisiones de consistencia y manejo de cortes regionales. 5. Principales compensaciones, cuellos de botella y al menos tres riesgos con mitigaciones. 6. Una breve estimación de capacidad para almacenamiento y rendimiento usando los números anteriores.
Diseño de sistemas
Diseñar un servicio global de acortamiento de URL
Diseñe un servicio público de acortamiento de URL similar a Bitly. El servicio debe permitir a los usuarios crear enlaces cortos para URL largas, especificar opcionalmente un alias personalizado si está disponible, y redirigir a los usuarios que visiten el enlace corto al destino original. Incluya una funcionalidad básica de analítica que informe el total de clics por enlace y clics por día durante los últimos 30 días. Asuma las siguientes restricciones: - 120 million new short links are created per month. - 1.2 billion redirect requests are served per month. - Read traffic is highly bursty, especially for viral links. - The service is used globally and users expect low-latency redirects. - Short links should remain valid for at least 5 years. - Redirect availability target is 99.99 percent. - Analytics may be eventually consistent by up to 10 minutes. - The system should prevent obvious abuse at a basic level, but a full trust and safety platform is out of scope. En su diseño, cubra: - High-level architecture and main components. - Data model and storage choices for link mappings and analytics. - ID or token generation strategy, including custom alias handling. - API design for creating links, redirecting, and fetching analytics. - Caching, partitioning, and replication strategy. - Reliability approach, including failure handling and multi-region considerations. - How you would scale for read-heavy traffic and viral hotspots. - Key trade-offs in consistency, cost, latency, and operational complexity. Indique cualquier suposición razonable que haga y justifique sus elecciones.
Diseño de sistemas
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.