Diseño de sistemas
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.
Diseño de sistemas: GPT-5 y Anthropic se agrupan arriba, Gemini queda atrás
OpenAI
Anthropic
OpenAI
Puntuacion media por modelo
Como ponderamos
Sobre 35 respuestas de diseño puntuadas, la cima es un grupo apretado de GPT-5 y Anthropic. GPT-5.5 (8,91) y Claude Opus 4.8 (8,69) ocupan los puestos 1 y 2 con registros perfectos, pero cada uno sobre una sola muestra, así que léelos como prometedores más que consolidados. Los mejores resultados evidenciados son GPT-5.4 (8,67 sobre 5 muestras, 60 % de victorias) y GPT-5 mini (8,43 sobre 4 muestras, 75 % de victorias), que tienen aquí el mayor peso.
La media y el orden divergen: GPT-5.4 supera en media a GPT-5 mini (8,67 frente a 8,43) pero queda por debajo, porque GPT-5 mini gana una mayor proporción de sus enfrentamientos (75 % frente a 60 %). Claude Sonnet 4.6 (8,53, 60 % sobre 5) está justo en este grupo, así que los seis primeros se separan por menos de medio punto en calidad y se ordenan sobre todo por victorias directas.
La línea Gemini forma un escalón inferior claro: 2.5 Pro (7,51), Flash (7,41) y Flash-Lite (7,12) no ganan ninguno de sus enfrentamientos y quedan entre 1,2 y 1,8 puntos de los líderes. Con Calidad de arquitectura ponderada al máximo (30) y Razonamiento de compromisos y Escalabilidad (20 cada una), la brecha apunta a un razonamiento más débil sobre estructura y compromisos, no a la presentación.
Los tamaños de muestra van de 1 a 6 por modelo, así que el orden fino dentro del grupo de 8 puntos es provisional y unos pocos prompts pueden mover cualquier media. La diferencia de 1,79 puntos entre el primero y el último es real, pero son medidas dependientes de las condiciones para prompts de diseño, no un veredicto universal.
En resumen
Para diseño de sistemas, GPT-5 mini es la elección diaria más defendible (75 % de victorias sobre 4 muestras), con GPT-5.4 como la opción de gama alta mejor evidenciada (8,67 sobre 5). Claude Sonnet 4.6 está prácticamente empatado en calidad; la línea Gemini queda claramente por detrás en este género.
Este analisis se basa en las puntuaciones de benchmark medidas por Orivel para este genero y se actualiza periodicamente. Las puntuaciones son medidas que dependen de las condiciones, no una verdad absoluta.
Ranking de modelos fuertes en este genero
Este ranking se ordena por la puntuacion media solo dentro de este genero.
Ultima actualizacion: 30 May 2026 09:41
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.5 | OpenAI |
100%
|
89
|
1 | 1 | Ver la evaluacion y la puntuacion de GPT-5.5 |
| #2 | Claude Opus 4.8 NUEVO | Anthropic |
100%
|
87
|
1 | 1 | Ver la evaluacion y la puntuacion de Claude Opus 4.8 |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Ver la evaluacion y la puntuacion de GPT-5 mini |
| #4 | GPT-5.4 | OpenAI |
60%
|
87
|
3 | 5 | Ver la evaluacion y la puntuacion de GPT-5.4 |
| #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 |
40%
|
82
|
2 | 5 | 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 | 6 | Ver la evaluacion y la puntuacion de Gemini 2.5 Flash | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | 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 sistema de pizarra colaborativa en tiempo real
Se le encomienda diseñar una arquitectura de sistema de alto nivel para una aplicación de pizarra colaborativa en tiempo real. **Requisitos principales:** 1. **Colaboración en tiempo real:** Varios usuarios (hasta 100 por sesión) pueden unirse a una única pizarra y ver las acciones de los demás (dibujar, añadir texto, mover objetos) en casi tiempo real (latencia inferior a 200 ms). 2. **Persistencia:** Las sesiones de pizarra deben guardarse para que los usuarios puedan cerrar la aplicación y reanudar su trabajo más tarde. 3. **Herramientas:** Los usuarios deben disponer de herramientas básicas como lápiz de trazo libre, cuadros de texto y notas adhesivas. **Restricciones de escala y fiabilidad:** * Soportar hasta 10.000 sesiones activas concurrentes de pizarra. * Soportar hasta 1.000.000 de usuarios en total. * El servicio debe ser altamente disponible, con un tiempo de actividad del 99,9%. **Tu tarea:** Proporcione un diseño del sistema que aborde los requisitos anteriores. Su respuesta debe cubrir: 1. **Arquitectura de alto nivel:** Un diagrama o descripción de los componentes principales (p. ej., clientes, balanceadores de carga, servidores de aplicaciones, bases de datos, servicios en tiempo real) y cómo interactúan. 2. **Comunicación en tiempo real:** Explique la tecnología y el protocolo que usaría para difundir las actualizaciones a todos los usuarios de una sesión. 3. **Modelo de datos:** Describa cómo estructuraría los datos de una pizarra, su contenido (dibujos, texto, etc.) y las sesiones de usuario. 4. **Estrategia de escalabilidad y fiabilidad:** ¿Cómo diseñaría el sistema para manejar la carga objetivo y garantizar alta disponibilidad? 5. **Compensaciones:** Discuta una compensación importante que haya hecho en su diseño (p. ej., consistencia frente a latencia, elección de base de datos, etc.).
Diseño de sistemas
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.
Diseño de sistemas
Diseñar un servicio de notificaciones escalable
Eres un ingeniero de software sénior en una empresa de redes sociales en rápido crecimiento. Tu tarea es diseñar un servicio de notificaciones escalable y fiable. Este servicio será responsable de enviar notificaciones a los usuarios sobre diversos eventos, como nuevos seguidores, me gusta en sus publicaciones, comentarios y mensajes directos.
Diseño de sistemas
Diseño de un servicio de notificaciones en tiempo real
Describe un diseño de sistema a alto nivel para un servicio de notificaciones en tiempo real para una plataforma de redes sociales. El servicio debe cumplir los siguientes requisitos: - **Escala:** 10 millones de Usuarios Activos Diarios (DAU). - **Volumen:** Cada usuario recibe un promedio de 20 notificaciones por día. - **Latencia:** Las notificaciones deben entregarse al dispositivo del usuario en menos de 2 segundos. - **Canales:** Soporte para notificaciones push (móvil), correo electrónico y notificaciones dentro de la aplicación. - **Confiabilidad:** 99.9% de disponibilidad y sin pérdida de datos de notificaciones. Tu diseño debe cubrir los siguientes aspectos: 1. **Arquitectura principal:** Describe los componentes clave (por ejemplo, API Gateway, Notification Service, Message Queue, Workers) y sus interacciones. 2. **Esquema de base de datos:** Propón un esquema de base de datos básico para almacenar las notificaciones de los usuarios y sus preferencias. 3. **Estrategia de escalado:** Explica cómo escalarías el sistema para manejar la carga especificada y el crecimiento futuro. 4. **Confiabilidad y tolerancia a fallos:** Detalla las medidas que tomarías para asegurar alta disponibilidad y prevenir pérdida de datos. 5. **Principales compensaciones:** Discute al menos dos compensaciones significativas que hiciste en tu diseño (por ejemplo, consistencia frente a disponibilidad, elección de base de datos, modelo push frente a pull).
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 cumplir las siguientes restricciones: 1. El servicio debe soportar 100 millones de nuevos acortamientos de URL por mes. 2. 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). 3. Las URL acortadas deben permanecer accesibles durante al menos 5 años después de su creación. 4. El sistema debe lograr una disponibilidad del 99,9%. 5. 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.
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.