Entrevista de diseño de sistemas: un método para cualquier pregunta.

El método en cinco fases (para una entrevista de 45 minutos)

1. Requisitos: 5 minutos. Separa los funcionales (“¿acortar una URL, redirigir, alias personalizados?”) de los no funcionales (escala, objetivos de latencia, disponibilidad frente a consistencia, durabilidad). Pide cifras: usuarios, proporción entre lecturas y escrituras, tamaño de los datos. Después di tu alcance en voz alta: “Voy a diseñar para 100 millones de usuarios activos diarios (DAU), con predominio de lecturas de 100:1 y redirecciones por debajo de 100 ms, y dejo fuera las analíticas salvo que nos sobre tiempo”. Acotar en voz alta es el gesto que más señal aporta en toda la ronda.
2. Estimación: 5 minutos. Cálculo rápido de QPS (consultas por segundo), almacenamiento y ancho de banda. Redondea a potencias de diez, explicita tus supuestos y comprueba que el resultado tenga sentido (“500 millones de URL nuevas al mes ≈ 200 escrituras/s, algo modesto; las lecturas a 100:1 ≈ 20 000/s, y eso es lo que condiciona el diseño”). No se trata de ser preciso, sino de demostrar que las cifras guían tus decisiones de arquitectura.
3. Diseño de alto nivel: 10 minutos. Cajas y flechas para el flujo principal: clientes, balanceador de carga, capa de aplicación sin estado, almacenes de datos, caché y cola. Recorre en voz alta una petición de principio a fin. Que sea aburrido: aquí la novedad es riesgo sin recompensa.
4. Análisis a fondo: 20 minutos. El entrevistador elige un componente (“¿cómo evita exactamente las colisiones la generación de ID?”, “¿qué pasa cuando muere un nodo de la caché?”). Aquí es donde se separan los niveles. Baja a lo concreto: modelo de datos, elección de la clave de partición, modos de fallo y qué despertaría a quien está de guardia a las 3 de la madrugada.
5. Cierre: 5 minutos. Los cuellos de botella que atacarías después, lo que vigilarías y lo que dejaste fuera a propósito. Terminar con las limitaciones conocidas se lee como nivel sénior, no como debilidad.

El vocabulario de trade-offs que demuestra un nivel sénior

Los entrevistadores se fijan en si recurres a estos ejes sin que te lo pidan:

Las diez preguntas más comunes de diseño de sistemas y la clave de cada una

1. Acortador de URL. La clave: la generación de ID (contador + base62 frente a hash + gestión de colisiones) y la caché en la ruta de lectura. Un calentamiento clásico: cuenta con repreguntas sobre analíticas y caducidad.
2. Sistema de chat (WhatsApp/Slack). La clave: la gestión de conexiones (WebSockets, presencia), el orden de los mensajes en cada conversación, las garantías y confirmaciones de entrega, y la sincronización sin conexión.
3. Feed de noticias (Twitter/Instagram). La clave: la estrategia de fan-out y el problema de las cuentas de famosos; el ranking como servicio aparte; la paginación con cursores, no con offsets.
4. Rate limiter (limitador de peticiones). La clave: la elección del algoritmo (token bucket frente a ventana deslizante), el conteo distribuido (Redis + Lua), el comportamiento ante fallos (fail-open o fail-closed) y dónde se coloca (en el gateway o en cada servicio).
5. Almacenamiento de archivos (Dropbox/Drive). La clave: la división en fragmentos y la deduplicación, el protocolo de sincronización y la resolución de conflictos, y la separación entre metadatos y blobs.
6. Plataforma de video (YouTube). La clave: el flujo de subida (transcodificación como trabajos asíncronos), la estrategia de CDN y el bitrate adaptativo; además, la economía del almacenamiento.
7. Asignación de viajes (Uber). La clave: la indexación geoespacial (geohash/quadtree), el volumen de escrituras de las actualizaciones de ubicación, la asignación como servicio con estado y la tarifa dinámica como un flujo de precios.
8. Sistema de notificaciones. La clave: la abstracción multicanal (push, correo, SMS), las preferencias y los límites de frecuencia por usuario, la idempotencia y los reintentos con deduplicación, y las colas de prioridad.
9. Caché distribuida. La clave: el hashing consistente, la política de expulsión, cache-aside frente a write-through y la protección contra el efecto estampida o thundering herd (agrupación de peticiones, TTL con jitter).
10. Sistema de métricas y monitoreo. La clave: el volumen de escrituras de series temporales, la reducción de resolución (downsampling) y los niveles de retención, la explosión de cardinalidad de las etiquetas y la evaluación de alertas como cómputo en streaming.

Practica al menos tres de principio a fin, en voz alta, en una pizarra o en un documento, al ritmo de 45 minutos. Narrar un diseño y escribirlo son habilidades distintas, y la entrevista puntúa la narración. Un simulacro con un asistente de entrevistas con IA te da feedback, a nivel de transcripción, sobre el punto exacto en el que tu explicación perdió el hilo; ChadFlow también puede ver la ventana de tu diagrama durante una ronda real y ayudarte cuando llega una repregunta.

Las cinco formas en que los candidatos fallan en la entrevista de diseño de sistemas

• Saltarse los requisitos. Diseñar de maravilla el sistema equivocado es el fallo más común. Treinta segundos acotando el alcance lo evitan.
• Estimar por aparentar. Hacer cuentas y después no usar nunca las cifras. Si tu estimación de QPS no cambia tu diseño, fue puro teatro.
• Arquitectura de palabras de moda. Soltar Kafka, Cassandra o Kubernetes sin la justificación basada en propiedades de la que hablamos arriba.
• Soltar un monólogo. La ronda es una prueba de colaboración. Pregunta de vez en cuando: “¿quieres que profundice en la capa de almacenamiento o paso a la API?”.
• No tener un plan ante fallos. Cada componente que dibujes debería tener una respuesta a “¿qué pasa cuando esto se cae?”. Prepara la respuesta antes de dibujar la caja.