Diseño de sistemas
Compara arquitectura, razonamiento de compromisos y calidad de diseño de sistemas.
En este género, las capacidades que más se intentan medir son Calidad de la arquitectura, Integridad, Análisis de compromisos.
A diferencia de coding, este género pesa más la arquitectura, la escala, la fiabilidad y los trade-offs que los detalles de implementación ejecutable.
Una puntuación alta aquí no significa que el modelo vaya a escribir el mejor código funcional ni la explicación más sencilla.
Para qué sirve un modelo fuerte en este género
propuestas de arquitectura, diseño de servicios y conversaciones sobre escalabilidad.
Lo que este género por sí solo no alcanza a mostrar
calidad de implementación de bajo nivel, corrección exacta o escritura para público no técnico.
Diseño de sistemas: Claude Opus 5 debuta en cabeza, el lado GPT aporta la profundidad de evidencia
Anthropic
OpenAI
OpenAI
Puntuación media por modelo
Cómo ponderamos
Claude Opus 5 se puso al frente de esta tabla con su primera aparición evaluada, y GPT-5.6 ha ganado todo lo que ha disputado hasta ahora. Ambos son registros tempranos: un gran debut en trabajo de arquitectura indica que el modelo razona sobre compromisos al nivel que los jueces premian, pero ninguno ha pasado aún la prueba de muchos encargos. Lee la cima como prometedora, no como probada.
GPT-5 mini vuelve a aportar la profundidad: más apariciones que los modelos por encima y un balance claramente ganador, lo que lo mantiene como el ancla respaldada por evidencia del género. GPT-5.5 muestra el patrón familiar de media alta con marcador repartido. Claude Sonnet 5 produjo un diseño respetable en su estreno pero perdió el duelo. La familia Gemini aún no se ha llevado ningún enfrentamiento aquí y sus medias quedan por debajo del pelotón.
Los jueces ponderan sobre todo la calidad de la arquitectura, con el razonamiento de compromisos, la escalabilidad y la completitud compartiendo el siguiente nivel — es un género donde nombrar los costes de tu diseño importa tanto como el diseño mismo. Las tareas de diseño de sistemas varían muchísimo en alcance, así que las muestras pequeñas oscilan aquí más que en la mayoría de géneros; toma el orden como la instantánea de una tabla que se mueve deprisa.
En resumen
Claude Opus 5 y GPT-5.6 parecen los rivales a batir por forma temprana, mientras GPT-5 mini sigue siendo la elección con evidencia real detrás. Los modelos Gemini todavía no convierten apariciones en victorias aquí.
Este análisis se basa en las puntuaciones de benchmark medidas por Orivel para este género y se actualiza periódicamente. Las puntuaciones son medidas que dependen de las condiciones, no una verdad absoluta.
Ranking de modelos fuertes en este género
Este ranking se ordena por la puntuación media solo dentro de este género.
Última actualización: 27 Jul 2026 09:44
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
Tasa de victoria
Puntuación media
| Modelos clasificados | Detalle | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Opus 5 NUEVO | Anthropic |
100%
|
92
|
1 | 1 | Ver la evaluación y la puntuación de Claude Opus 5 |
| #2 | GPT-5.6 | OpenAI |
100%
|
90
|
2 | 2 | Ver la evaluación y la puntuación de GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Ver la evaluación y la puntuación de GPT-5 mini |
| #4 | GPT-5.5 | OpenAI |
50%
|
87
|
1 | 2 | Ver la evaluación y la puntuación de GPT-5.5 |
| #5 | Claude Sonnet 5 NUEVO | Anthropic |
0%
|
83
|
0 | 1 | Ver la evaluación y la puntuación de Claude Sonnet 5 |
| #6 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Ver la evaluación y la puntuación de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | Ver la evaluación y la puntuación de Gemini 2.5 Flash | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
68
|
0 | 5 | Ver la evaluación y la puntuación de Gemini 2.5 Flash-Lite |
Qué se evalúa en Diseño de sistemas
Criterios y pesos usados para este ranking por género.
Calidad de la arquitectura
30.0%
Este criterio se incluye para comprobar Calidad de la arquitectura en la respuesta. Tiene más peso porque este aspecto cambia mucho el resultado global del género.
Integridad
20.0%
Este criterio se incluye para comprobar Integridad en la respuesta. Tiene un peso importante porque afecta a la calidad de forma visible, aunque no sea lo único que importa.
Análisis de compromisos
20.0%
Este criterio se incluye para comprobar Análisis de compromisos en la respuesta. Tiene un peso importante porque afecta a la calidad de forma visible, aunque no sea lo único 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 a la calidad de forma visible, aunque no sea lo único que importa.
Claridad
10.0%
Este criterio se incluye para comprobar Claridad en la respuesta. Tiene menos peso porque acompaña al objetivo principal, pero no define por sí solo este género.
Tareas recientes
Diseño de sistemas
Diseñar un sistema de notificaciones en tiempo real para una aplicación de redes sociales
Eres un ingeniero de software sénior encargado de diseñar un sistema de notificaciones en tiempo real para una aplicación de redes sociales en rápido crecimiento. El sistema debe ser escalable, fiable y entregar notificaciones con baja latencia. Proporciona una propuesta detallada de diseño del sistema.
Diseño de sistemas
Diseño de sistema: Servicio de notificaciones en tiempo real
Eres un ingeniero de software senior encargado de diseñar un sistema de notificaciones en tiempo real para una gran plataforma de redes sociales. Requisitos del sistema: Funcionalidad: El sistema debe entregar notificaciones por varias interacciones de usuario, incluyendo nuevos seguidores, "me gusta" en publicaciones, comentarios y mensajes directos. Entrega en tiempo real: Las notificaciones deben entregarse a usuarios en línea con muy baja latencia (menos de 2 segundos). Compatibilidad multiplataforma: El sistema debe soportar el envío de notificaciones vía push móvil (iOS/Android), notificaciones en navegadores web y correo electrónico. Historial de notificaciones: Los usuarios deben poder ver un historial de sus notificaciones recientes (p. ej., los últimos 100). Escalabilidad: El sistema debe manejar 100 millones de usuarios activos diarios (DAU), con cada usuario generando un promedio de 10 eventos que desencadenan notificaciones por día. También debe manejar picos de carga de 5x el tráfico promedio. Confiabilidad: El sistema debe ser altamente disponible (99.9% de tiempo de actividad) y resiliente a fallos. Tu tarea: Proporciona un plan de diseño de sistema detallado. Tu plan debe cubrir los siguientes aspectos: Una visión arquitectónica de alto nivel. Componentes clave y sus responsabilidades (p. ej., API Gateway, Servicio de Notificaciones, Servicio de Fan-out, etc.). Modelo de datos y elección de bases de datos (p. ej., para almacenar preferencias de usuario, historial de notificaciones). Justifica tus elecciones. Recomendaciones de pila tecnológica (p. ej., colas de mensajes, capas de caché, servicios de notificaciones push). Estrategias para asegurar escalabilidad, baja latencia y alta disponibilidad. Una discusión sobre los posibles cuellos de botella y los compromisos realizados en tu diseño.
Diseño de sistemas
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.
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: 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). Persistencia: Las sesiones de pizarra deben guardarse para que los usuarios puedan cerrar la aplicación y reanudar su trabajo más tarde. 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: 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. 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. Modelo de datos: Describa cómo estructuraría los datos de una pizarra, su contenido (dibujos, texto, etc.) y las sesiones de usuario. Estrategia de escalabilidad y fiabilidad: ¿Cómo diseñaría el sistema para manejar la carga objetivo y garantizar alta disponibilidad? 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.