Entrevista de diseño de sistemas: cómo estructurar tu respuesta
Intención de búsqueda: Ingenieros de nivel medio a sénior que conocen los sistemas distribuidos pero se bloquean cuando les piden diseñarlos en vivo frente a un entrevistador.
Por qué los buenos ingenieros fallan en entrevistas de diseño de sistemas
Has construido sistemas distribuidos. Has depurado incidentes en producción. Sabes qué es un CDN. Y aun así, cuando alguien dice "Diseña Twitter," tu mente se queda en blanco.
El problema no es el conocimiento — es la estructura. Las preguntas de diseño de sistemas son deliberadamente abiertas. Sin un marco claro, saltas entre componentes, olvidas clarificar requisitos y te quedas sin tiempo antes de haber cubierto lo importante.
Los entrevistadores no califican tu diagrama final. Están observando cómo piensas: ¿recopilas requisitos, propones un diseño, identificas cuellos de botella y razonas sobre compromisos? Eso es lo que realmente evalúa la entrevista de diseño de sistemas.
El marco de 5 pasos para cualquier entrevista de diseño de sistemas
Paso 1: Clarifica los requisitos (3–5 minutos)
Antes de dibujar nada, haz preguntas. Esto no es ganar tiempo — es la parte más importante.
Requisitos funcionales — qué debe hacer el sistema:
- ¿Cuáles son las acciones principales del usuario? (publicar, leer, buscar, seguir)
- ¿Qué casos de uso están fuera del alcance?
Requisitos no funcionales — cómo debe comportarse el sistema:
- Escala: ¿cuántos usuarios activos diarios? ¿Es de lectura intensa o escritura intensa?
- Objetivos de latencia: ¿qué es aceptable para la acción principal del usuario?
- Disponibilidad: ¿cuál es el SLA de tiempo activo? ¿Podemos tolerar breves interrupciones durante los despliegues?
- Consistencia: ¿se requiere consistencia fuerte o es suficiente la eventual?
Anota los números. "1M usuarios diarios, ratio lectura/escritura 100:1, p99 < 200ms para lecturas" — esto determina cada decisión arquitectónica que tomes.
No omitas este paso aunque el enunciado parezca claro. Los entrevistadores dejan la ambigüedad intencionalmente para ver si preguntas.
Paso 2: Estima la escala (2–3 minutos)
Los cálculos de orden de magnitud fundamentan tu diseño. Para un sistema de lectura intensa con 10M de usuarios activos diarios:
- Supón 50 lecturas/día por usuario → 500M lecturas/día → ~6.000 lecturas/segundo
- Almacenamiento: si cada registro pesa 1KB y almacenas 10M registros nuevos/día → 10GB/día → 3,6TB/año
Estos números te dicen si necesitas una sola base de datos o fragmentación, si un solo nodo de caché es suficiente, y cómo debe ser tu estrategia de CDN.
Paso 3: Diseño de alto nivel (10–12 minutos)
Ahora dibuja. Empieza con el diseño más simple que satisfaga tus requisitos. Un buen diseño de alto nivel para la mayoría de los sistemas incluye:
- Cliente → API Gateway → Servicios de aplicación
- Bases de datos — ¿qué tipo y por qué? (relacional, NoSQL, series temporales)
- Caché — ¿qué cacheas y por qué?
- Procesamiento asíncrono — ¿dónde encaja una cola de mensajes?
- CDN — para contenido estático o lecturas distribuidas geográficamente
Por ejemplo, un acortador de URLs a escala:
- Ruta de escritura: Cliente → API → Servidor de aplicación → BD (escribe mapeo corto:largo) + Caché
- Ruta de lectura: Cliente → CDN → Balanceador de carga → Servidor de aplicación → Caché (Redis) → BD si falla la caché
- Generación de URL corta: Usa un ID basado en contador con codificación base-62 o un generador de ID distribuido (Snowflake)
Di tus elecciones en voz alta: "Aquí uso PostgreSQL porque los datos son relacionales y necesitamos consistencia fuerte para escrituras. Para lecturas, pondré Redis delante."
Paso 4: Análisis profundo (10–15 minutos)
Tras el diseño de alto nivel, el entrevistador normalmente te guiará hacia las áreas que más le importan. Temas comunes de análisis profundo:
- Diseño del esquema de base de datos — ¿cuáles son tus tablas, índices, estrategia de fragmentación?
- Estrategia de caché — ¿cache-aside vs. write-through? ¿TTL? ¿Invalidación de caché?
- Manejo de puntos calientes — ¿qué pasa cuando las publicaciones de un usuario famoso reciben 10M de visitas?
- Consistencia vs. disponibilidad — ¿dónde estás haciendo ese compromiso explícitamente?
- Fan-out de datos — para feeds sociales, ¿cómo propagas escrituras a los seguidores?
Profundiza cuando te lo pidan. El entrevistador quiere verte ir más allá de "pon una caché delante de la base de datos" a "aquí está la política de desalojo, así manejo las avalanchas de caché, este es el compromiso que estoy asumiendo."
Paso 5: Compromisos y alternativas (5 minutos)
Cierra reconociendo lo que dejaste fuera o simplificaste deliberadamente. Esto separa a los buenos candidatos de los excelentes.
"Aquí elegí consistencia eventual para obtener mejor rendimiento de escritura — pero si el negocio requiriera que cada lectura refleje la última escritura, tendría que repensar esto con replicación síncrona, lo que añade latencia."
Esto señala madurez de ingeniería: entiendes que cada decisión arquitectónica es un compromiso, no una respuesta correcta.
Preguntas comunes de diseño de sistemas y qué evalúan realmente
| Pregunta | Qué evalúan realmente |
|---|---|
| Diseña un acortador de URLs | Hashing, almacenamiento, alto throughput de lectura, caché |
| Diseña el feed de Twitter/Instagram | Estrategias de fan-out, consistencia eventual, CDN |
| Diseña un limitador de tasa | Token bucket vs. leaky bucket, contadores distribuidos |
| Diseña un sistema de notificaciones | Procesamiento asíncrono, colas de mensajes, lógica de reintento |
| Diseña una caché distribuida | Hashing consistente, replicación, políticas de desalojo |
Los mayores errores en entrevistas de diseño de sistemas
Saltar directamente al código o a los diagramas. Empieza siempre con los requisitos, aunque el problema parezca obvio.
Diseñar el sistema perfecto. No existe el sistema perfecto. El entrevistador quiere razonamiento sobre compromisos, no un diagrama de libro de texto.
Quedarse en silencio. Narra tu pensamiento en voz alta. Si estás considerando dos enfoques, dilo. "Estoy eligiendo entre X e Y — X nos da mejor rendimiento de escritura pero Y es más fácil de escalar en lecturas. Dado nuestro ratio de lectura 100:1, voy con Y."
Ignorar la escala. Cada decisión debe conectar de vuelta a tus números. "Esto funciona a 1K QPS, pero a 100K QPS necesitaríamos fragmentar — así es como lo abordaría."
Practica ahora
Conocer el marco y aplicarlo en vivo bajo presión de entrevista son dos cosas muy diferentes.