Entrevistas de System Design: Framework, Ejemplos y Práctica

Introducción

La mayoría de los candidatos que suspenden una entrevista de system design no fallan por falta de conocimiento. Fallan porque empiezan a dibujar cajas antes de hacer una sola pregunta, o porque recitan nombres de tecnologías sin explicar por qué encajan en el problema que tienen delante.

Las entrevistas de system design evalúan tu capacidad de razonar sobre problemas ambiguos y abiertos. No hay una respuesta correcta esperando al final; hay una conversación que el entrevistador usa para observar cómo acotas, descompones, cuantificas y defiendes decisiones. Esta guía te da una estructura repetible para esa conversación, los conceptos que se espera que expliques con soltura y dos ejemplos resueltos con números reales.

Lo que el Entrevistador Realmente Está Puntuando

Antes de aprender frameworks, conviene saber qué se está evaluando. Las rúbricas varían según la empresa, pero casi siempre cubren las mismas cinco dimensiones:

• Descubrimiento del problema. ¿Aclaraste requerimientos y restricciones antes de diseñar? Los seniors preguntan “¿cuántos usuarios?” antes de dibujar nada; los juniors empiezan a dibujar de inmediato.
• Razonamiento estructurado. ¿Descompusiste el problema en componentes y los atacaste en un orden sensato, o saltaste aleatoriamente entre temas?
• Análisis de trade-offs. Cada decisión tiene un coste. “Usamos una base de datos relacional” suma pocos puntos; “usamos una base de datos relacional porque necesitamos integridad transaccional para pagos, a costa de un escalado horizontal más difícil” es lo que los entrevistadores escuchan.
• Pensamiento cuantitativo. ¿Puedes convertir “muy popular” en requests por segundo, gigabytes por día y tasas de acierto de caché? Los cálculos aproximados separan a los seniors de los juniors más rápido que cualquier palabra de moda.
• Comunicación. ¿Narras tu razonamiento, verificas con el entrevistador y tratas sus pistas como requerimientos? Piénsala como diseñar en pareja con un colega, no como defender una tesis.

Dos señales importan más que el resto: hacer preguntas aclaratorias primero y establecer suposiciones explícitamente. Los entrevistadores perdonan el conocimiento que falta; rara vez perdonan diseñar con confianza el sistema equivocado.

El Framework 4S

Una respuesta sólida sigue cuatro fases: Scope, Sketch, Scale, Solidify. El framework existe para prevenir los dos modos de fallo más comunes: resolver el problema equivocado y quedarse sin tiempo en medio de la parte interesante.

1. Scope (2-3 minutos)

Aclara los requerimientos antes de diseñar nada. Escríbelos en la pizarra para que el entrevistador pueda corregirte pronto — una suposición corregida en el minuto tres no cuesta nada; una suposición equivocada descubierta en el minuto treinta cuesta la entrevista.

Requerimientos funcionales:

• ¿Qué capacidades debe soportar el sistema?
• ¿Cuáles son los casos de uso principales, y cuáles quedan fuera del alcance?

Requerimientos no funcionales:

• Escala: ¿cuántos usuarios? ¿Requests por segundo? ¿Ratio lectura-escritura?
• Latencia: ¿cuál es un tiempo de respuesta aceptable?
• Disponibilidad: ¿qué uptime se requiere — 99.9% o 99.99%?
• Consistencia: ¿las lecturas toleran consistencia eventual o deben ser fuertes?

Ejemplo: para “diseña un acortador de URLs como bit.ly”, una buena fase de scope produce:

• Funcional: acortar una URL, redirigir, alias personalizados, analítica de clics.
• Escala: 100M URLs nuevas/día, 10B redirecciones/día — un ratio lectura-escritura de 100:1.
• Latencia: menos de 50 ms para las redirecciones.
• Disponibilidad: 99.99%, porque las redirecciones están en el camino crítico del producto.

Ese resultado del scope ya implica la arquitectura: lectura intensiva significa caché agresiva; 100:1 significa que el camino de escritura puede ser más lento que el de lectura; la analítica implica un pipeline asíncrono, no escrituras síncronas.

2. Sketch (10-15 minutos)

Dibuja un diseño de alto nivel con los componentes principales, y narra cada caja mientras la dibujas. El esbozo no necesita ser correcto — necesita ser una base sobre la que el entrevistador pueda reaccionar.

Los componentes que conviene dominar:

• Balanceador de carga: distribuye tráfico entre servidores (round-robin, least connections).
• API gateway: autenticación, rate limiting y enrutamiento en el borde.
• Servidores de aplicación: sin estado, para escalar horizontalmente sin coordinación.
• Caché: Redis o Memcached para datos calientes; réplicas de lectura para queries calientes.
• Base de datos: SQL vs. NoSQL es en sí una pregunta de trade-offs — ver cómo elegir.
• Cola de mensajes: Kafka o RabbitMQ para desacoplar trabajo lento o irregular.
• CDN: assets estáticos y caché de borde cerca de los usuarios.
• Object storage: almacenes estilo S3 para archivos y multimedia.

Resiste la tentación de nombrar vendors en el esbozo (“object storage” en lugar de “S3”). Demuestra que piensas en roles, no en folletos de producto.

3. Scale (10-15 minutos)

Ahora nombra tú los cuellos de botella — antes de que el entrevistador los señale — y elimínalos en orden de impacto. Un hábito útil: por cada cuello de botella que nombres, di cómo lo detectarías (“nuestra latencia p99 de lectura subiría” o “el throughput de escritura saturaría la primaria”).

Cuello de botella	Solución de primera línea
Tráfico de lectura intensiva	Caché + CDN + réplicas de lectura
Tráfico de escritura intensiva	Sharding + colas de mensajes
Punto único de fallo	Despliegue multi-AZ, replicación, failover
Queries lentas	Índices, desnormalización, índices de búsqueda dedicados
Almacenamiento de archivos grandes	Object storage + presigned URLs

Matemática aproximada. Di los números en voz alta mientras los calculas; los entrevistadores evalúan el proceso, no la aritmética:

100M URLs/día  ≈ 1,160 escrituras/s   (pico ~3,000/s)
10B lecturas/día  ≈ 115,000 lecturas/s  (pico ~300,000/s)

Registro de URL: short_code (6 B) + long_url (500 B) + metadata (100 B) ≈ 600 B

Almacenamiento: 100M × 600 B ≈ 60 GB/día ≈ 22 TB/año

Números como estos justifican decisiones: 60 GB/día es tan pequeño que una única primaria maneja las escrituras durante años; 300k lecturas/s no, así que el camino de lectura necesita una caché que absorba más del 95% del tráfico.

4. Solidify (5-10 minutos)

Cierra cubriendo lo que pasa cuando la realidad interfiere:

• Monitoreo: percentiles de latencia, tasa de error, tasa de acierto de caché, profundidad de cola.
• Seguridad: rate limiting, validación de entradas, detección de abuso.
• Retención de datos: política de archivado, solicitudes de eliminación (GDPR).
• Disaster recovery: backups, point-in-time recovery, objetivos RPO/RTO.

Si queda tiempo, nombra proactivamente la debilidad de tu propio diseño — “este esquema funciona hasta que una URL se vuelve viral, momento en el que esa clave de caché se convierte en un hot spot” es un cierre más fuerte que cualquier diagrama.

Conceptos que Conviene Explicar Bien

Escalado Horizontal vs. Vertical

	Vertical	Horizontal
Enfoque	Máquina más grande	Más máquinas
Límite	Tope de hardware	Casi ilimitado
Coste	Caro por unidad	Más barato por unidad a escala
Downtime	Normalmente requiere algo	Despliegues rolling, sin downtime
Complejidad	Simple	Requiere balanceo de carga y estado distribuido

La respuesta que los entrevistadores quieren no es “escala horizontal siempre” — es “escala verticalmente hasta que la complejidad de la distribución esté justificada”. Una base de datos primaria suele permanecer vertical más tiempo que cualquier otra pieza del sistema, precisamente porque el estado distribuido es caro.

Sharding de Base de Datos

El sharding particiona los datos entre múltiples bases de datos para que ningún nodo soporte toda la carga:

Shard por user_id % 4:
  Usuario 1 → Shard 0     Usuario 4 → Shard 3
  Usuario 2 → Shard 1     Usuario 5 → Shard 0
  Usuario 3 → Shard 2

Elegir la shard key es la verdadera pregunta de la entrevista. Una buena shard key tiene alta cardinalidad (muchos valores distintos), produce distribución uniforme (sin hotspots cuando una clave es una celebridad con 100M seguidores) y coincide con el patrón de queries dominante (localidad de queries — la mayoría de las queries incluyen la clave). Menciona el resharding: cambiar la clave después es doloroso, así que elígela para donde estará el sistema, no donde está. Para el tratamiento completo, ver la guía completa de sharding de bases de datos.

Estrategias de Caching

Estrategia	Cómo funciona	Caso de uso
Cache-aside	La app revisa la caché, carga de la DB en miss	Lectura intensiva; la app controla la lógica
Read-through	La caché obtiene de la DB transparentemente	Lógica de aplicación más simple
Write-through	Las escrituras actualizan caché y DB juntas	Consistencia fuerte en lecturas
Write-behind	Las escrituras van a caché, flush asíncrono a DB	Escritura intensiva; tolera retraso

Dos temas de seguimiento que encantan a los entrevistadores: estampidas de caché (cuando una clave caliente expira y miles de requests golpean la base de datos simultáneamente — se mitiga con locking o recálculo temprano) e invalidación (decidir cuándo un dato en caché está obsoleto — TTLs, purga explícita al escribir, o claves versionadas). El manual completo está en la receta de estrategias de caching.

El Teorema CAP — y lo que Viene Después

En un sistema distribuido solo puedes garantizar dos de tres propiedades:

• Consistencia: todos los nodos ven los mismos datos al mismo tiempo.
• Disponibilidad: cada request recibe una respuesta.
• Tolerancia a particiones: el sistema sigue funcionando a pesar de fallos de red.

La versión práctica: las particiones no son opcionales, así que la elección real es CP o AP durante una partición. PACELC lo extiende un paso más — si hay partición, elige disponibilidad o consistencia; si no, elige latencia o consistencia. Esa segunda cláusula es donde viven la mayoría de los trade-offs reales: incluso sin partición, una consistencia más fuerte cuesta round-trips. La guía del teorema CAP cubre PACELC y el ajuste por sistema en profundidad.

Ejemplo Resuelto: Diseñar un Acortador de URLs

Es el problema de entrevista canónico, y merece ensayarse de principio a fin. Requerimientos de la fase de scope: acortar URLs, redirigir rápido, soportar alias personalizados, recolectar analítica de clics. 100M escrituras/día, 10B lecturas/día, <50 ms en redirecciones, 99.99% de disponibilidad.

Paso 1 — Estimación de capacidad. La matemática de la fase Scope da ~1,160 escrituras/s y ~115,000 lecturas/s. El almacenamiento resulta en unos 60 GB/día y ~21 TB/año — suficientemente pequeño para que la planificación de capacidad trate de throughput de lectura, no de disco.

Paso 2 — Diseño de API. Tres endpoints cubren el contrato:

POST /api/v1/shorten
  Body:     { "url": "https://example.com/...", "custom_alias": "my-link" }
  Response: { "short_url": "https://s.io/my-link", "code": "my-link" }

GET /:code
  Response: redirección 301 a long_url
  Headers:  Cache-Control: public, max-age=31536000

GET /api/v1/stats/:code
  Response: { "clicks": 12345, "unique_visitors": 8900 }

El 301 con una vida de caché larga es deliberado: las redirecciones permanentes se pueden cachear en el borde del CDN, lo que elimina carga antes de que llegue a la aplicación.

Paso 3 — Generación del short code. Tres opciones, cada una con un trade-off real:

• Base62 de un ID auto-incremental. Sin colisiones y ordenable, pero predecible — cualquiera puede enumerar todas las URLs acortadas. Se corrige aplicando XOR al ID con un secreto, o aceptando la enumeración como no-objetivo.
• Hash + truncado. Tomar los primeros 7 caracteres base62 de MD5(long_url). La misma URL produce el mismo código (deduplicación gratis), pero necesitas lógica de reintento ante colisiones.
• ID distribuido (estilo Snowflake). Un ID de 64 bits con timestamp + worker + secuencia no necesita coordinación y no tiene colisiones, a costa de códigos más largos.

Una elección defendible: auto-incremental con ofuscación XOR — simple, sin colisiones, no enumerable.

Paso 4 — Modelo de datos. Divide la carga por patrón de acceso en lugar de forzar a un solo motor a hacerlo todo:

-- PostgreSQL: mapeo de URLs (OLTP, bajo volumen de escritura)
CREATE TABLE url_mappings (
    short_code VARCHAR(7) PRIMARY KEY,
    long_url   TEXT NOT NULL,
    user_id    BIGINT,
    created_at TIMESTAMP DEFAULT now(),
    expires_at TIMESTAMP
);

-- Cassandra: eventos de clic (analítica de escritura intensiva)
CREATE TABLE click_events (
    short_code text,
    clicked_at timestamp,
    ip_address text,
    user_agent text,
    referrer   text,
    PRIMARY KEY (short_code, clicked_at)
) WITH CLUSTERING ORDER BY (clicked_at DESC);

Los eventos de clic son append-only, de alto volumen y se consultan por código — la carga de trabajo ideal de un wide-column store. El mapeo de URLs cabe en una tabla relacional pequeña — y la mayoría de las lecturas ni siquiera llegan a ella, las absorbe la caché.

Paso 5 — Arquitectura. El diseño ensamblado:

Paso 6 — Estrategia de caching. Redis mapea short_code → long_url con un TTL de 24 horas; el CDN cachea la propia respuesta 301. Apunta a una tasa de acierto >95% para que solo ~5% de las lecturas lleguen a PostgreSQL. Al actualizar o expirar una URL, borra la clave de Redis y purga la entrada del CDN.

Paso 7 — Sharding (cuando se hace necesario). Con ~3,000 escrituras/s de pico una única primaria está cómoda durante años; el sharding es una preocupación del año dos. Cuando llegue, haz shard por hash(short_code) — es la clave que cada lectura ya lleva. Dieciséis shards con tres réplicas de lectura cada uno llevan la capacidad de lectura a ~320k lecturas/s con margen.

Paso 8 — Preocupaciones operacionales. Alerta sobre latencia p99 de redirección por encima de 100 ms, tasa de acierto de caché por debajo del 90% y tasa de error por encima del 0.1%. PostgreSQL recibe point-in-time recovery; el RPO del diseño es inferior a un minuto y el RTO inferior a quince minutos con standby multi-AZ.

Un Segundo Ejemplo: Diseñar un Sistema de Chat

El sistema de chat prueba músculos distintos al acortador de URLs — entrega en tiempo real y ordenación en lugar de economía de caché — y por eso los entrevistadores lo usan para comprobar si realmente entendiste el primer ejemplo o solo lo memorizaste.

Las preguntas de scope revelan el problema real: ¿chat 1:1 o en grupo? ¿Presencia en línea? ¿Historial de mensajes y búsqueda? ¿Garantías de entrega? Una app de chat “simple” a escala son en realidad tres sistemas: un pipeline de mensajes, un servicio de presencia y un almacén de historial.

Trade-offs para nombrar en voz alta mientras dibujas:

• Entrega en tiempo real: conexiones WebSocket persistentes vs. long polling. A escala, haces shard de conexiones por usuario y enrutas mensajes a través de una capa pub/sub; la receta de WebSockets en tiempo real cubre la mecánica.
• Ordenación de mensajes: no existe un reloj global, así que ordenas por conversación — un número de secuencia por conversación o un reloj de Lamport.
• Fan-out: en chats de grupo, decide según el tamaño del grupo si empujas a la bandeja de cada miembro de forma ansiosa o dejas que los miembros hagan pull — el mismo trade-off push-vs-pull que el fan-out de un feed.
• Almacenamiento: mensajes recientes en un almacén rápido claveado por conversación; historial en un almacén más barato particionado por conversación y tiempo.

Si puedes contrastar este caso con el acortador — “aquí las lecturas son baratas pero la semántica de entrega es difícil; allí la entrega era trivial pero el volumen de lectura dominaba” — estás demostrando transferencia de razonamiento, que es la habilidad que realmente se evalúa.

Expectativas por Nivel

La exigencia cambia según el nivel al que aspiras:

Nivel	Qué se espera
Junior	Enfoque estructurado, componentes básicos, disposición a hacer preguntas. Profundidad en una o dos áreas basta.
Mid-level	Vocabulario correcto de trade-offs, matemática de capacidad sin que se lo pidan, un diseño completo de principio a fin.
Senior	Conduce la entrevista proactivamente, cuantifica cada afirmación, discute modos de fallo sin que se lo recuerden.
Staff+	Diseña para la evolución: cambios del modelo de datos, multi-región, restricciones organizativas, coste. Menciona lo que no construiría todavía.

La mayor señal de nivel es si optimizas para la escala declarada o para una escala imaginaria. Una respuesta junior diseña para mil millones de usuarios; una respuesta staff diseña para 100M y dice exactamente dónde se rompe.

Gestionar los 45 Minutos

Un presupuesto de tiempo que sobrevive al contacto con una entrevista real:

Fase	Presupuesto	Cómo se ve “hecho”
Scope	2-3 min	Requerimientos escritos, suposiciones establecidas
Sketch	10-15 min	Componentes en la pizarra, flujo de datos narrado
Scale	10-15 min	Cuellos de botella eliminados, matemática en la pizarra
Solidify	5-10 min	Operación, casos borde, autocrítica
Margen	~5 min	Tangentes del entrevistador — no son gratis, protégelas

Si terminas antes, no dejes de hablar — elige un componente y profundízalo. La entrevista termina cuando el entrevistador está satisfecho, no cuando tu diagrama está terminado.

Cómo Practicar

El system design es una habilidad de ejecución; leer sobre ella no es practicarla.

• Ensaya en voz alta, con tiempo. Dos o tres simulacros por semana a 40 minutos. Explica tu razonamiento mientras dibujas — el silencio se lee como inseguridad incluso cuando sabes la respuesta.
• Memoriza los números. Latencia de lectura en memoria (~100 ns), lectura de SSD (~100 µs), round-trip de red (~500 µs intra-DC), seek de disco (~10 ms), un request a través del Atlántico (~150 ms). Esto convierte “rápido” y “lento” en argumentos.
• Estudia arquitecturas reales. Los blogs de ingeniería y los postmortems (cómo Discord almacena mensajes, cómo Stripe maneja idempotencia) te dan detalle de producción que las guías genéricas no tienen.
• Resuelve el mismo problema dos veces. Resuelve un problema una vez, lee una solución canónica, resuélvelo de nuevo una semana después y anota dónde divergieron tus decisiones.
• Grábate. Las muletillas, las transiciones ausentes (“ahora ataco el camino de lectura”) y el tiempo perdido son invisibles hasta que los escuchas.

Un Banco de Preguntas para Ensayar

Estos son los clásicos a los que los entrevistadores recurren. Trabájalos aproximadamente en este orden — cada pregunta entrena un músculo distinto:

• Diseña un rate limiter: estado del token bucket, contadores distribuidos, consistencia en el borde.
• Diseña un web crawler: colas de frontera, cortesía, deduplicación a escala de mil millones de páginas.
• Diseña un sistema de chat: entrega en tiempo real, ordenación, presencia — esbozado arriba.
• Diseña un news feed / Twitter: fan-out push vs. pull, el problema de las celebridades, señales de ranking.
• Diseña una caché distribuida: sharding, evicción, replicación — las tripas de Redis a la inversa.
• Diseña un servicio de ride-sharing: índices geoespaciales, matching, lógica de surge, máquinas de estado.
• Diseña una plataforma de video: object storage, estrategia de CDN, pipelines de subida, procesamiento de miniaturas.
• Diseña sincronización de archivos (Dropbox): chunking, deduplicación, delta sync, resolución de conflictos.
• Diseña un pipeline de métricas: ingesta de escritura intensiva, almacenamiento de series temporales, rollups.
• Diseña un key-value store: modelos de consistencia, lecturas y escrituras con quórum, protocolos gossip — el clásico “diseña Dynamo”.

Resuelve cada una en frío a 40 minutos, luego vuelve a resolver las que te dejaron atascado. Una pregunta que ensayaste dos veces rara vez es la que te hace fallar; una categoría sin practicar sí lo es.

Lo que Funciona

• Empieza simple, luego agrega complejidad solo cuando los requerimientos declarados la justifiquen.
• Establece suposiciones explícitamente — los entrevistadores puntúan tu razonamiento, no tus conclusiones.
• Cuantifica afirmaciones: “lectura intensiva” no significa nada hasta que se convierte en “ratio lectura-escritura de 100:1”.
• Conoce a fondo tu propio stack; nunca propongas una tecnología que no puedas explicar dos niveles más abajo.
• Trata las pistas del entrevistador como requerimientos, no como sugerencias a considerar luego.
• Practica con cronómetro. Cuarenta y cinco minutos pasan más rápido de lo que crees.

Errores Comunes

• Saltar a un esquema de base de datos detallado antes de aclarar un solo requerimiento.
• Ignorar los requerimientos no funcionales — escala, disponibilidad, consistencia — hasta el final.
• Proponer tecnologías sin entenderlas (“usa Kafka” sin poder decir por qué una cola gana a una llamada directa aquí).
• No discutir trade-offs, por ejemplo, pasar por alto SQL vs. NoSQL como si la elección fuera gratis.
• Olvidar el monitoreo, la seguridad y las preocupaciones operacionales hasta que te lo recuerden.
• Diseñar para escala infinita cuando los requerimientos declarados no la justifican — señala razonamiento de cargo cult, no seniority.
• Quedarte en silencio mientras dibujas. Narra continuamente o el entrevistador no puede puntuar tu razonamiento.

Véase También

• Companion ejecutable — los artefactos del acortador de URLs de esta guía: estimador de capacidad, esquemas y contrato de API.
• System Design Primer (donnemartin/system-design-primer) — el repositorio de referencia para preparar entrevistas, con casos resueltos y recursos de estudio.
• Designing Data-Intensive Applications — el libro de Martin Kleppmann; el tratamiento más profundo de los trade-offs de almacenamiento, replicación y particionamiento.
• Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services — la presentación original de CAP por Seth Gilbert y Nancy Lynch.
• Documentación de sharding de MongoDB — guía de shard keys de producción directamente de un sistema que la distribuye.
• ByteByteGo — los casos de system design visuales de Alex Xu, útiles para ver soluciones completas narradas.