La entrevista de system design es la ronda que la mayoria de los ingenieros con experiencia prepara mal. Se aprenden de memoria el diseno de un acortador de URLs, lo recitan bajo presion y salen con un rechazo porque el entrevistador estaba puntuando otra cosa. Lo que realmente se mide es como razonas cuando el enunciado esta incompleto a proposito.
Que puntua de verdad el entrevistador
Nadie espera una arquitectura de produccion en 45 minutos. La rubrica se parece mas a esto:
- Pensamiento estructurado. Sabes imponer un orden a un enunciado vago, en voz alta, para que el entrevistador pueda seguirte?
- Clarificacion de requisitos. Preguntas que debe hacer el sistema antes de decidir como lo hace?
- Compromisos explicitos. Cada eleccion cuesta algo. Nombras ese coste o presentas tus decisiones como gratuitas?
- Saber cuando parar. Sigues optimizando un componente que no es el cuello de botella o pasas al siguiente?
Recitar una arquitectura memorizada te perjudica. Indica que no sabras adaptarte cuando el entrevistador cambie una restriccion, cosa que hara.
El presupuesto de 45 minutos
La gestion del tiempo forma parte de la nota, no es un detalle administrativo. Un reparto que funciona:
- 5 min: clarificar y acotar. Quien usa el sistema, cuales son las operaciones centrales, que queda explicitamente fuera de alcance.
- 5 min: estimacion aproximada. Trafico, almacenamiento, ratio lectura/escritura.
- 10 min: diseno de alto nivel. Cajas, flechas, flujo de datos. Nada profundo todavia.
- 15 min: deep dive. El entrevistador elige uno o dos componentes. Ahi se juega la mayor parte de la senal.
- 5-10 min: cuellos de botella, modos de fallo y cierre.
Anuncia el plan al principio. "Voy a dedicar unos cinco minutos a los requisitos, luego estimo, luego dibujo el alto nivel y despues profundizamos donde quieras." Esa sola frase ya demuestra estructura.
Escribe los requisitos antes que nada
Es el habito de mayor rendimiento de toda la entrevista, y es el que la mayoria de los candidatos se salta.
Divide la pizarra en dos:
Funcionales - lo que hace el sistema. "El usuario sube un video. Otros lo ven. Se puede buscar por titulo." De tres a cinco puntos, no mas.
No funcionales - las propiedades que restringen el diseno. Escala esperada, objetivos de latencia, disponibilidad, requisitos de consistencia, durabilidad, perfil de lectura o de escritura.
Escribirlos produce tres efectos: el entrevistador te corrige pronto si has leido mal el enunciado, tienes un punto de apoyo al que volver cuando justifiques una decision, y evitas disenar una funcionalidad que nadie pidio. Son los requisitos no funcionales los que dirigen la arquitectura. "Fuertemente consistente" y "consistente en ultima instancia" producen sistemas completamente distintos a partir del mismo requisito funcional.
Estimar sin fingir precision
El calculo aproximado no busca acertar. Busca fijar un orden de magnitud para saber si necesitas una base de datos o un cluster con sharding.
Recorre:
- QPS. Usuarios activos diarios por acciones de cada uno, dividido entre 86.400 segundos. Luego multiplica por 2 o 3 para el pico.
- Ratio lectura/escritura. Un sistema de 100 lecturas por cada escritura justifica cache agresivo y replicas de lectura. Uno intensivo en escritura, no.
- Crecimiento de almacenamiento. Tamano medio del objeto por escrituras al dia por retencion. Por dia y por ano.
Enuncia cada supuesto en voz alta: "Voy a asumir 10 millones de activos diarios y unas 5 acciones cada uno, o sea unos 500 millones de peticiones al dia, digamos 6.000 QPS de media y 15.000 en pico." Si el entrevistador no esta de acuerdo con la cifra te lo dira, y ajustar con limpieza ya es una senal positiva. Nunca te inventes un numero en silencio y lo presentes como un hecho.
Los bloques que conviene entender de verdad
Necesitas conocimiento operativo de estos elementos, no diagramas memorizados. De cada uno: que problema resuelve y que te cuesta.
- Load balancing - L4 frente a L7, health checks, sesiones pegajosas y por que complican el escalado.
- Cache e invalidacion - cache-aside frente a write-through, estrategia de TTL, y el hecho de que la invalidacion es la parte dificil.
- SQL frente a NoSQL - se elige por patron de acceso, no por moda. Transacciones multi-entidad y consultas libres: relacional. Clave conocida y gran volumen de escritura: documental o wide-column.
- Sharding y clave de particion - la eleccion de la clave de particion es el diseno. Una mala clave da shards calientes y consultas cross-shard.
- Replicacion y consistencia - leader-follower, retraso de replicacion, que ve el usuario cuando lee su propia escritura.
- Colas y procesamiento asincrono - que desacoplas, y los problemas de backpressure y de orden que heredas.
- CDN - descarga de estaticos y media, cabeceras de cache, retardo de invalidacion.
- Rate limiting - token bucket, donde colocarlo, por usuario o por IP.
- Idempotencia - claves de idempotencia en las escrituras, porque a escala los reintentos estan garantizados.
Como hablar de compromisos
La formula que puntua es simple: eleccion, motivo, coste.
"Pondria un cache Redis delante del servicio de perfiles porque el ratio lectura/escritura ronda 100 a 1. El coste son lecturas obsoletas hasta que expire el TTL, y una estampida en arranque en frio si el cache se cae. Lo mitigaria con request coalescing."
Comparalo con "anadiria cache para mejorar el rendimiento". Misma decision, la mitad de puntos.
Cuando no sabes algo
Vas a topar con un hueco durante el deep dive. Lo correcto es decirlo y despues razonar.
"No he implementado consenso directamente, asi que no conozco los detalles internos de Raft. Lo que si se es que necesito un unico leader por particion y una forma de elegir uno nuevo sin split-brain, o sea un quorum. Razonemos desde ahi."
Eso se contrata. El farol con aplomo no, y se detecta en una sola pregunta de seguimiento.
Un plan de 4 semanas trabajando a jornada completa
Semana 1 - fundamentos. Dos horas por tema de la lista de bloques. Escribe media pagina de cada uno: que resuelve, que cuesta, cuando no usarlo.
Semana 2 - leer sistemas reales. Blogs de ingenieria de empresas que operan a gran escala. Fijate en por que cambiaron algo, no en como es su diagrama final.
Semana 3 - practicar en voz alta. De cuatro a seis disenos completos de 45 minutos, cronometrados, hablados y con una herramienta de dibujo abierta. Grabate. La distancia entre pensar un diseno y narrarlo es mayor de lo que parece.
Semana 4 - profundizar en los huecos. Coge los dos componentes en los que mas te trabaste y baja un nivel. Haz dos simulacros con una persona real.
Practica en pizarra o en una herramienta de dibujo compartida desde el primer dia. Dibujar mientras hablas es una habilidad aparte y se degrada mucho si solo lo has hecho en tu cabeza.
Errores mas frecuentes
- Lanzarse al diagrama antes de que nadie haya acordado que hace el sistema.
- Pensar en silencio. Treinta segundos callado se leen como bloqueo. Verbaliza.
- Sobre-disenar para una escala imaginaria. No se hace sharding para 100 QPS.
- Ignorar el modelo de datos. Muestra las entidades clave y los patrones de acceso principales. Muchos candidatos no escriben ni una sola tabla.
- Ninguna gestion de fallos. Que pasa cuando ese nodo muere, cuando esa cola se acumula, cuando esa dependencia se ralentiza?
Variantes: frontend, datos y ML
El marco es el mismo, cambian los componentes.
- El system design de frontend gira en torno a la estrategia de renderizado, la gestion de estado, la entrega de bundles y assets, el modo offline, el diseno del contrato de API y la accesibilidad, no al sharding de bases de datos.
- Data engineering se centra en batch frente a streaming, evolucion de esquemas, pipelines idempotentes, datos que llegan tarde, backfills y coste por consulta.
- El ML system design anade feature stores, desviacion entre entrenamiento y serving, versionado y rollback de modelos, evaluacion online frente a offline, y presupuesto de latencia en inferencia.
Una nota para perfiles senior
A nivel senior se da por supuesto el conocimiento de componentes. Lo que separa las notas es el acotado y la priorizacion: decidir que dejar fuera, decir que parte del sistema concentra el riesgo real, y elegir tu mismo el tema del deep dive cuando el entrevistador te deja la iniciativa. Si disenas todo con la misma profundidad, pareces alguien que nunca ha tenido que entregar con una fecha encima.
Puntos clave
- Escribe los requisitos funcionales y no funcionales en la pizarra antes de dibujar nada. Es el habito mas rentable de la entrevista.
- Reparte los 45 minutos de forma explicita y anuncia el plan en voz alta.
- Estima al orden de magnitud, enuncia tus supuestos y no inventes precision.
- Nombra el coste de cada eleccion. Una decision sin compromiso declarado parece suerte.
- Cuando no sepas algo, dilo y razona desde los principios basicos. El farol se detecta al instante.