Entrevista de System Design: Framework de Preparación Paso a Paso

Fracasé estrepitosamente en mi primera entrevista de system design. No de forma “casi, pero no” — de forma “dibujé cajas random durante cuarenta minutos y recibí el email de rechazo antes de cenar.”

Lo frustrante es que yo realmente sabía de sistemas distribuidos. Había construido servicios que manejaban tráfico real de producción. Pero cuando el entrevistador dijo “Diseña un URL shortener,” mi cerebro simplemente… se paró. Tenía el conocimiento y cero proceso para aplicarlo bajo presión.

Esa brecha — entre saber cosas y estructurar tu pensamiento sobre la marcha — es lo que la preparación para entrevistas de system design debería resolver primero. No memorizar arquitecturas. Proceso.

Un Framework Es Solo una Muleta (Y Está Bien)

Después de ese desastre me construí una secuencia repetible que llamo URDGE: Understand, Requirements, Design, Gaps, Evaluate. Cinco pasos, aproximadamente 35-45 minutos en total.

Quiero ser honesto: el acrónimo no es mágico. Muchos ingenieros tienen su propia variación. El valor está en la restricción misma. Cuando sabes cuál es tu siguiente paso, dejas de entrar en pánico sobre por dónde empezar. Simplemente… empiezas.

Lo que la mayoría de los consejos de preparación no te dicen — los entrevistadores no están evaluando tu arquitectura. Están observando cómo navegas la ambigüedad y hablas sobre trade-offs. Un diseño mediocre, comunicado con claridad y un enfoque estructurado, le gana a una arquitectura brillante entregada como un monólogo confuso. Lo he visto pasar desde ambos lados de la mesa.

Los Dos Pasos Que Todo el Mundo Se Salta

Scoping y requisitos. Los candidatos los pasan en noventa segundos y luego se preguntan por qué su diseño se descarrila en el minuto veinte.

Scoping (3-5 minutos): No toques la pizarra. Reformula el problema. Haz preguntas de clarificación. Los entrevistadores dejan los enunciados vagos a propósito — quieren ver si profundizas en la ambigüedad o la atropellas.

Preguntas que siempre hago:

• ¿Quiénes son los usuarios? ¿Consumidores, empresas, herramientas internas?
• ¿Cuál es el caso de uso principal? (“Sistema de chat” podría ser cinco productos diferentes.)
• ¿Cuál es la escala esperada — DAUs, requests por segundo, volumen de datos?
• ¿Alguna restricción dura? ¿Objetivos de latencia, compliance, residencia de datos?

Escribe las respuestas. Se convierten en tu documento informal de requisitos para los treinta minutos restantes.

Requisitos (3-5 minutos): Ahora separa en funcionales y no funcionales. Para un URL shortener, los funcionales son directos: crear URLs cortas, redirigir a las originales, quizás aliases personalizados. Los no funcionales es donde demuestras profundidad — 99.99% de disponibilidad en lectura, redirecciones sub-100ms, 100M de URLs creadas por mes.

Luego haz las cuentas. En voz alta.

100M de escrituras por mes son aproximadamente 40 escrituras/segundo. Con una relación lectura-escritura de 10:1, son 400 lecturas/segundo. Cada registro son unos 500 bytes, así que estás viendo ~50 GB/mes, 600 GB/año. Esto ancla tu diseño en la realidad. Te dice si necesitas una base de datos o una flota de ellas. Si el caching es un nice-to-have o una cuestión de supervivencia.

A los entrevistadores les encantan los cálculos back-of-the-envelope. Separan el razonamiento de nivel senior del hand-waving.

Dibujar Cajas — La Parte Con La Que Todos Se Obsesionan

Esto es lo que la mayoría de los candidatos consideran “la entrevista de verdad.” Yo diría que en realidad es el paso más fácil si has hecho bien los dos anteriores. Opinión controversial quizás, pero el trabajo de scoping es lo que hace o rompe tu diseño. La fase de arquitectura es solo ejecución.

Empieza por la API, no por la infraestructura. Define el contrato antes de los internals:

• POST /urls — recibe una URL larga, devuelve una corta
• GET /{shortCode} — redirección 301/302 a la original

Luego dibuja el flujo de alto nivel. Cliente, load balancer, servidor de aplicación, base de datos, cache. Cajas simples, flechas con etiquetas. Nada elegante todavía.

Luego profundiza en las partes interesantes. Para el URL shortening, tienes varias estrategias de generación — codificación base62 de un ID auto-incremental (simple pero necesita un contador centralizado), hash truncado (riesgo de colisión), o un servicio de claves pre-generadas (escalable, sin colisiones, más overhead operacional). Elige una. Justifícala. Nombra lo que estás sacrificando.

La elección de base de datos sigue los patrones de acceso. Esto es fundamentalmente key-value — shortCode mapea a longURL. DynamoDB encaja naturalmente. Postgres también funciona, pero eventualmente necesitarás sharding. Dilo en voz alta; no lo escondas.

Para el caching, una relación lectura-escritura de 10:1 más distribución Pareto (el 20% de las URLs genera el 80% del tráfico) hace que un Redis read-through cache sea casi obligatorio. LRU eviction lo mantiene manejable.

No apuntes a un diseño perfecto. Apunta a uno claro. Son cosas diferentes, y los entrevistadores lo saben.

Rompe Tu Propio Diseño Antes de Que Lo Haga el Entrevistador

Este es el paso que separa a los candidatos sólidos de los impresionantes. La mayoría se detiene después de dibujar su arquitectura. No lo hagas.

¿Qué pasa si la base de datos se cae? Las lecturas cacheadas sobreviven, pero las escrituras no — así que querrías replicación multi-AZ con failover automático. ¿Y las hot keys, una URL viral martillando un solo nodo de cache? Replica las hot keys entre nodos. ¿Escenarios de abuso? Rate limiting por IP o API key, algoritmo token bucket.

Analytics es una trampa sigilosa. Loggear cada redirección de forma síncrona mata tu presupuesto de latencia. Envía eventos a Kafka, procésalos asincrónicamente.

No necesitas resolver cada brecha. Honestamente, no puedes en 45 minutos. Identificarlas es el punto. Saber qué puede romperse antes de que se rompa — eso es lo que parece la ingeniería senior, y los entrevistadores lo reconocen inmediatamente.

Cierra nombrando tus trade-offs explícitamente. “Elegimos NoSQL por el rendimiento key-value, pero sacrificamos queries complejas entre registros. Si analytics se convierte en un caso de uso primario, añadiríamos un store analítico separado.” La mayoría de los candidatos se saltan esto. No seas la mayoría.

Deja de Memorizar, Empieza a Practicar

El framework URDGE te da proceso, pero aún necesitas un vocabulario de bloques de construcción — load balancers (L4 vs L7), estrategias de caching (read-through vs write-behind), tipos de bases de datos, message queues, CDNs. Estúdialos por separado para que aparezcan con fluidez durante la entrevista en lugar de fragmentos a medio recordar.

Practica seis a ocho problemas diferentes usando este framework. No para memorizar soluciones, sino para construir memoria muscular con el enfoque. Después de unos cuantos problemas, el scoping, las cuentas, las discusiones de trade-offs… empiezan a sentirse como segunda naturaleza.

Ahí es cuando las entrevistas de system design dejan de dar miedo y empiezan a ser conversaciones. Que — si lo piensas — es lo que se suponía que fueran desde el principio.

FAQ

P: ¿Cuánto tiempo debería dedicar a preparar entrevistas de system design?

Depende de dónde partes. Si has construido sistemas en producción, dos a tres semanas de práctica enfocada suele ser suficiente. Si los sistemas distribuidos son más nuevos para ti, date seis a ocho semanas. La clave es practicar el proceso con diferentes problemas, no leer sobre arquitecturas pasivamente. La práctica activa siempre le gana al estudio pasivo.

P: ¿Funciona el framework URDGE para entrevistas de nivel staff o principal engineer?

El esqueleto funciona, pero las expectativas cambian. A niveles de staff+, los entrevistadores esperan que profundices más en temas operacionales — observabilidad, estrategia de deploy, modos de fallo, trade-offs organizacionales. El framework te da la estructura; tu experiencia rellena la profundidad. Pasarás menos tiempo en lo básico y más en las fases de “stress-test” y “trade-offs.”

P: ¿Qué pasa si el entrevistador interrumpe mi flujo del framework?

Bien — significa que está enganchado. Adáptate. El framework no es un guion; es una red de seguridad. Si quiere saltar directamente a la elección de base de datos, ve ahí. Siempre puedes volver a los huecos del scoping después. Aferrarte rígidamente a tu secuencia cuando el entrevistador está dirigiendo hacia otro lado queda peor que adaptarte.

P: ¿Debería practicar en una pizarra o vale con papel?

Pizarra si puedes, aunque sea una barata comprada online apoyada contra la pared. La restricción del espacio físico cambia cómo organizas la información — aprendes a dejar sitio, escribir más grande, estructurar visualmente. El papel funciona para la práctica de razonamiento, pero las habilidades espaciales importan más de lo que la gente espera.

El system design es solo una ronda. Para un plan de preparación completo que cubra coding, comportamental y logística, lee cómo preparar una entrevista técnica. Y cuando estés listo para practicar con una plantilla, usa la plantilla de respuesta para system design.

¿Listo? Unirme al acceso anticipado →