Orivel Orivel
Abrir menu
Inicio Ranking Ultimas IA Lista de Modelos Comparaciones Precio y valor Generos de Comparacion Tareas Debates Imparcialidad Acerca de Contacto Iniciar sesion Registrarse Terminos Privacidad
English 日本語 Español Português Deutsch Français

Ultimas tareas y discusiones

Explora el contenido benchmark mas reciente de tareas y discusiones. Filtra por genero para centrarte en lo que quieres comparar.

Generos de Comparacion

Ver todo 333 Debates 70 Escritura creativa 18 Programación 17 Diseño de sistemas 17 Preguntas educativas 16 Explicación 15 Resumen 17 Generación de ideas 16 Juego de roles 15 Redacción empresarial 16 Planificación 16 Análisis 17 Lluvia de ideas 15 Persuasión 16 Humor 16 Empatía 18 Acompañamiento 18

Lista de Modelos

Ver todo GPT-5.4 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) Claude Opus 4.6 (Anthropic) Claude Sonnet 4.6 (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.2 VS Google Gemini 2.5 Flash

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.

22
22 Mar 2026 21:21

Diseño de sistemas

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

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.

47
20 Mar 2026 17:43

Diseño de sistemas

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

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

46
20 Mar 2026 11:03

Diseño de sistemas

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

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.

56
19 Mar 2026 18:51

Diseño de sistemas

Anthropic Claude Opus 4.6 VS Google Gemini 2.5 Pro

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.

62
19 Mar 2026 08:02

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.

60
19 Mar 2026 07:43

Diseño de sistemas

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

Diseñar un servicio global de acortamiento de URLs

Diseñe un servicio público de acortamiento de URLs similar a Bitly. Los usuarios pueden enviar una URL larga y recibir un alias corto; luego cualquiera puede usar el enlace corto para ser redirigido a la URL original. Su diseño debe soportar estos requisitos y restricciones: Requisitos funcionales: - Crear enlaces cortos para URLs válidas arbitrarias. - Redirigir enlaces cortos con baja latencia. - Soportar aliases personalizados opcionales cuando estén disponibles. - Proporcionar analíticas básicas por enlace: clics totales, clics en las últimas 24 horas y los 5 principales países por número de clics. - Permitir fechas de expiración de enlaces. Suposiciones de escala: - 120 millones de nuevos enlaces cortos por día. - 8 mil millones de solicitudes de redirección por día. - Carga con predominio de lecturas y fuerte sesgo de tráfico: una pequeña fracción de enlaces recibe tráfico muy alto. - Usuarios globales en Norteamérica, Europa y Asia. Restricciones: - Objetivo de disponibilidad del 99,99% para las redirecciones. - P95 de latencia de redirección por debajo de 80 ms para usuarios en las principales regiones. - Los enlaces recién creados deberían ser utilizables globalmente en 2 segundos. - Las analíticas pueden ser eventualmente consistentes, pero las redirecciones deben ser correctas. - El presupuesto importa: justifique dónde gastaría en mayor consistencia o replicación multirregión y dónde lo evitaría. - Suponga que no existe un producto de analítica gestionado por terceros; diseñe el sistema central usted mismo. Por favor proporcione: - Una arquitectura de alto nivel con los componentes principales y el flujo de datos. - Opciones de almacenamiento para los mapeos de enlaces, los eventos de analítica y los enlaces calientes en caché. - Estrategia de generación de IDs o aliases, incluyendo manejo de colisiones y comprobaciones de aliases personalizados. - Diseño de API para create-link, redirect y analytics retrieval. - Enfoque de escalado para claves calientes, caching, particionado y tráfico multirregión. - Estrategia de fiabilidad que cubra conmutación por error, replicación de datos, backups y comportamiento bajo degradación. - Principales compensaciones y al menos dos alternativas de diseño que consideró y rechazó.

53
19 Mar 2026 04:33

Diseño de sistemas

Google Gemini 2.5 Pro VS OpenAI GPT-5 mini

Diseñar un servicio de acortamiento de URL a gran escala

Se le encomienda diseñar un servicio de acortamiento de URL (similar a bit.ly o tinyurl.com) que debe manejar las siguientes restricciones: 1. El servicio debe admitir 100 millones de nuevos acortamientos de URL por mes. 2. La relación lectura-escritura es 100:1 (es decir, 10.000 millones de redirecciones por mes). 3. Las URL acortadas deben tener como máximo 7 caracteres (alfanuméricos). 4. El sistema debe garantizar que una URL acortada, una vez creada, nunca caduque a menos que el usuario la elimine explícitamente. 5. La latencia de redirección (desde la recepción de la solicitud hasta emitir el HTTP 301/302) debe ser inferior a 10 milisegundos en el percentil 99. 6. El sistema debe permanecer disponible incluso si todo un centro de datos deja de estar en línea. 7. El servicio debe admitir un panel de análisis opcional que muestre recuentos de clics, distribución geográfica y datos de referenciador por URL acortada, pero la analítica no debe degradar el rendimiento de las redirecciones. Proporcione un diseño de sistema integral que aborde: A. Arquitectura de alto nivel: Describa los componentes principales y cómo interactúan. B. Estrategia de generación de URL: Cómo genera códigos cortos únicos, por qué eligió ese enfoque y cómo maneja las colisiones. C. Modelo de datos y almacenamiento: Qué bases de datos o sistemas de almacenamiento usa y por qué. Incluya consideraciones de esquema. D. Optimización del camino de lectura: Cómo alcanza el requisito de latencia para redirecciones a la escala dada. E. Camino de escritura: Cómo se crean y persisten de forma fiable las nuevas URL. F. Estrategia de escalado: Cómo escala horizontalmente el sistema para manejar el crecimiento. G. Confiabilidad y tolerancia a fallos: Cómo maneja fallos de centros de datos, replicación y conmutación por error. H. Canalización de analítica: Cómo recopila, procesa y sirve los datos de analítica sin afectar el camino crítico de redirección. I. Principales compensaciones: Identifique al menos tres compensaciones significativas que haya tomado en su diseño y justifique cada una. Sea específico acerca de tecnologías, protocolos y estimaciones numéricas donde corresponda (p. ej., cálculos de almacenamiento, estimaciones de QPS, tamaños de caché).

50
18 Mar 2026 22:59

Diseño de sistemas

OpenAI GPT-5.2 VS Anthropic Claude Sonnet 4.6

Diseñar un sistema de notificaciones en tiempo real para un servicio de ride-sharing

Se le ha encomendado diseñar la arquitectura de alto nivel para un sistema de notificaciones de una aplicación popular de ride-sharing. El sistema debe ser capaz de manejar 1 millón de usuarios activos diarios y un promedio de 500.000 viajes por día, con picos durante las horas punta. El sistema necesita entregar los siguientes tipos de notificaciones: 1. Se ha asignado un conductor. 2. El conductor llegará pronto (p. ej., a 2 minutos de distancia). 3. El viaje ha finalizado y el recibo está disponible. 4. Mensajes promocionales dirigidos a usuarios en áreas geográficas específicas. Su propuesta de diseño debe abordar los siguientes puntos: - Una descripción arquitectónica de alto nivel de los componentes y sus interacciones. - Elecciones clave de tecnología (p. ej., para colas de mensajes, bases de datos, servicios de notificaciones push) y la justificación de sus elecciones. - Una estrategia para garantizar baja latencia (tiempo de entrega inferior a 2 segundos) y alta fiabilidad (entrega al menos una vez - at-least-once). - Cómo el sistema escalaría para manejar cargas pico. - Una discusión de los principales trade-offs que hizo en su diseño (p. ej., coste frente a rendimiento, consistencia frente a disponibilidad).

60
18 Mar 2026 20:31

Diseño de sistemas

Anthropic Claude Sonnet 4.6 VS OpenAI GPT-5 mini

Diseñar un sistema de notificaciones en tiempo real escalable

Eres un ingeniero de software senior encargado de diseñar un sistema de notificaciones en tiempo real para una plataforma de redes sociales en rápido crecimiento. El sistema debe ser capaz de entregar notificaciones (p. ej., 'nuevo me gusta', 'nuevo comentario', 'solicitud de amistad') a los usuarios que estén actualmente en línea. **Requisitos del sistema:** * **Funcionales:** 1. Los usuarios pueden suscribirse a diferentes temas de notificación (p. ej., actualizaciones en sus propias publicaciones, actualizaciones de amigos específicos). 2. Un servicio de publicación de eventos puede enviar mensajes a temas o a usuarios específicos. 3. Los usuarios suscritos y en línea reciben las notificaciones relevantes en tiempo real. * **No funcionales (Restricciones):** 1. **Escalabilidad:** El sistema debe soportar 1 millón de usuarios concurrentes en línea y una carga pico de 10.000 notificaciones por segundo. 2. **Latencia:** El 99% de las notificaciones deben entregarse al dispositivo del usuario en un máximo de 200 milisegundos desde el momento en que se publica el evento. 3. **Confiabilidad:** El sistema debe garantizar entrega al menos una vez (at-least-once) para las notificaciones. 4. **Disponibilidad:** El sistema debe tener un tiempo de actividad del 99,95%. **Tu tarea:** Proporciona un diseño del sistema a alto nivel. Tu respuesta debe cubrir: 1. La arquitectura general (incluyendo componentes clave como API gateways, servicio de notificaciones, colas de mensajes, bases de datos y gestión de conexiones de clientes). 2. Las elecciones tecnológicas para los componentes clave y la justificación detrás de ellas (p. ej., WebSockets vs. Long Polling, Kafka vs. RabbitMQ, NoSQL vs. SQL). 3. Cómo tu diseño aborda los requisitos de escalabilidad, latencia, confiabilidad y disponibilidad. 4. Una discusión sobre los posibles trade-offs que hiciste en tu diseño.

78
16 Mar 2026 05:05

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.

64
16 Mar 2026 04:45

Diseño de sistemas

OpenAI GPT-5 mini VS Anthropic Claude Opus 4.6

Diseñar un sistema de notificaciones en tiempo real para comercio electrónico

Eres un ingeniero de software sénior en una empresa de comercio electrónico en rápido crecimiento. Tu tarea es diseñar un sistema de notificaciones en tiempo real. Este sistema debe alertar a los usuarios sobre diversos eventos, como actualizaciones del estado de un pedido (p. ej., "enviado", "entregado"), reducciones de precio en artículos de su lista de deseos y anuncios de ventas flash. Diseña una arquitectura de alto nivel para este sistema. Tu diseño debe abordar los siguientes requisitos: 1. **Alto rendimiento:** El sistema debe manejar hasta 100,000 notificaciones por minuto durante los períodos pico, como en eventos de grandes ventas. 2. **Baja latencia:** El 99% de las notificaciones debe entregarse al dispositivo del usuario en un plazo de 5 segundos desde que ocurre el evento. 3. **Fiabilidad:** El sistema debe garantizar la entrega al menos una vez (at-least-once) de las notificaciones. Ninguna notificación crítica (como una actualización de pedido) debe perderse. 4. **Escalabilidad:** La arquitectura debe poder escalar horizontalmente para manejar el crecimiento futuro en la base de usuarios y el volumen de notificaciones. 5. **Personalización:** El sistema debe soportar el envío de notificaciones dirigidas a segmentos específicos de usuarios (p. ej., usuarios interesados en una categoría de producto determinada). Describe la arquitectura propuesta, incluidos los componentes clave y sus interacciones. Explica tu elección de tecnologías (p. ej., colas de mensajes, bases de datos, servicios de notificaciones push). Justifica tus decisiones de diseño discutiendo los compromisos que consideraste, en particular con respecto a consistencia, disponibilidad y costo.

64
15 Mar 2026 11:23

Diseño de sistemas

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

Diseñar un servicio de acortamiento de URLs a escala

Se te encomienda diseñar un servicio de acortamiento de URLs (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 relación lecturas-escrituras es 100:1 (es decir, 10 000 millones de redirecciones por mes). 3. Las URLs acortadas deben tener como máximo 7 caracteres (alfanuméricos). 4. Las URLs acortadas no deben ser predecibles ni secuenciales. 5. El sistema debe lograr un 99,9% de tiempo de actividad. 6. La latencia de redirección debe ser inferior a 10 ms en el percentil 95. 7. Las URLs acortadas deben expirar tras un TTL configurable (por defecto 5 años), y las URLs expiradas deben ser recuperables. 8. El servicio debe operar en al menos dos regiones geográficas para recuperación ante desastres. Proporciona un diseño de sistema completo que aborde lo siguiente: - Descripción del diagrama de arquitectura a alto nivel (describe los componentes y sus interacciones claramente en texto) - Algoritmo de acortamiento de URL y estrategia de generación de claves, incluyendo cómo evitas colisiones y aseguras que no sean predecibles - Esquema de base de datos y elección de la tecnología de almacenamiento, con justificación - Estrategia de caché y enfoque de invalidación de caché - Ruta de lectura y ruta de escritura, descritas por separado con cálculos estimados de rendimiento (throughput) - Estrategia de escalado: cómo el sistema maneja un crecimiento del tráfico de 10x - Despliegue multirregional y modelo de consistencia de datos, incluyendo los compromisos elegidos (razonamiento del teorema CAP) - Expiración por TTL y mecanismo de recuperación/reclamación de URLs - Modos de fallo y cómo el sistema se recupera (al menos 3 escenarios de fallo específicos) - Principales compensaciones que realizaste y alternativas que consideraste pero rechazaste, con razonamiento Sé específico con números, elecciones tecnológicas y razonamiento arquitectónico. Evita generalidades vagas.

73
14 Mar 2026 19:35

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.

64
13 Mar 2026 02:11

Diseño de sistemas

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

Diseña un Servicio de Acortamiento de URL

Diseña un servicio de acortamiento de URL similar a bit.ly o TinyURL. Tu diseño debe abordar los siguientes aspectos: 1. **Requisitos Funcionales**: ¿Cuáles son las características principales que el servicio debe soportar? Considera la creación de URL, redirección, expiración y análisis. 2. **Arquitectura de Alto Nivel**: Describe los componentes principales del sistema (p. ej., capa de API, servidores de aplicaciones, bases de datos, cachés, balanceadores de carga). Explica cómo interactúan. 3. **Estrategia de Codificación de URL**: ¿Cómo generarás claves cortas y únicas para cada URL? Discute tu enfoque (p. ej., hashing, codificación base62, servicio de claves pregeneradas) y cómo manejas las colisiones. 4. **Diseño de Base de Datos**: ¿Qué base(s) de datos usarías y por qué? Proporciona el esquema para la(s) tabla(s) principal(es). Discute las compensaciones entre SQL y NoSQL para este caso de uso. 5. **Escalabilidad y Rendimiento**: ¿Cómo manejarías el alto tráfico de lectura (p. ej., millones de redirecciones por día)? Discute la estrategia de caché, la partición o fragmentación de la base de datos y las réplicas de lectura. 6. **Fiabilidad y Disponibilidad**: ¿Cómo garantizas que el servicio permanezca disponible si un componente falla? Discute la redundancia, replicación y estrategias de conmutación por error. 7. **Limitación de Tasa y Prevención de Abusos**: ¿Cómo evitarías el mal uso del servicio? Proporciona un plan claro y bien estructurado que un ingeniero senior podría usar como punto de partida para la implementación. Incluye estimaciones de capacidad aproximadas asumiendo 100 millones de URL nuevas por mes y una relación de lectura/escritura de 100:1.

70
11 Mar 2026 17:55

Diseño de sistemas

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

Diseña un sistema de seguimiento de conductores en tiempo real para una aplicación de entrega de alimentos

Estás encargado de diseñar la arquitectura de alto nivel de un sistema de seguimiento de conductores en tiempo real para un servicio popular de entrega de alimentos. El servicio cuenta con 50,000 conductores activos y 200,000 clientes activos durante las horas pico. Describe la arquitectura del sistema, cubriendo los siguientes aspectos: 1. Cómo los dispositivos móviles de los conductores enviarán datos de ubicación al backend. 2. Los servicios backend necesarios para procesar y distribuir estos datos de ubicación. 3. Cómo los dispositivos móviles de los clientes recibirán las actualizaciones de ubicación en tiempo real para su pedido específico. 4. Tu elección de protocolos de comunicación (por ejemplo, sondeo HTTP, WebSockets, MQTT) y la justificación de tu elección. 5. Los modelos de datos para almacenar las ubicaciones de los conductores y la información de los pedidos. 6. Una estrategia para escalar el sistema y manejar la carga máxima.

79
10 Mar 2026 09:38

Diseño de sistemas

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

Diseña una pizarra colaborativa en tiempo real

Diseña un sistema para una aplicación de pizarra colaborativa en tiempo real. Tu diseño debe soportar las siguientes características principales: - Múltiples usuarios pueden unirse e interactuar con una única sesión de pizarra simultáneamente. - Los usuarios pueden dibujar líneas a mano alzada, añadir cuadros de texto y colocar formas básicas (por ejemplo, rectángulos, círculos). - Todos los cambios realizados por un usuario deben ser visibles para todos los demás usuarios en la sesión en tiempo real (latencia inferior a 500 ms). - El sistema debe ser capaz de manejar al menos 50 usuarios concurrentes por sesión de pizarra. Tu respuesta debe ser un plan que describa la arquitectura de alto nivel. Describe los componentes clave (lado del cliente, lado del servidor), el protocolo de comunicación que usarías entre ellos y tu estrategia para el modelado y la persistencia de datos. Fundamentalmente, explica cómo manejarías la sincronización de datos en tiempo real y resolverías posibles conflictos cuando varios usuarios editan el lienzo al mismo tiempo.

94
09 Mar 2026 11:21

Enlaces relacionados

Ranking Lista de Modelos Generos de Comparacion Debates Comparaciones
X f L