#16 - Cómo preparar entrevistas de System Design
Cómo no entrar en pánico cuando te pidan diseñar YouTube en una hora
Las entrevistas de diseño de sistemas asustan. Te dan un problema muy abierto y, en menos de una hora, tienes que diseñar algo decente.
“Hay cientos de ingenieros trabajando en YouTube desde hace dos décadas. Cómo voy a poder diseñarlo yo sólo en una hora?”. Valid crashout xD.
Tras hacer cientos de entrevistas, tanto como entrevistador como candidato, voy a resumirte las claves del diseño de sistemas en este post.
En mi curso Diseño de Sistemas a Gran Escala y Arquitectura de Software cubro todo el proceso desde cero, con 7 casos reales:
Diseñar sistemas con alta escalabilidad, disponibilidad y fiabilidad.
Conceptos clave en el diseño de sistemas (load balancer, cdn, message brokers, cache y mucho más)
Patrones de Arquitectura Software.
7 casos prácticos reales.
Únete a los más de 6500 estudiantes y 4.7 / 5 ⭐️ de valoración!
Qué se busca realmente en las entrevistas de Diseño de Sistemas
Antes que nada: no, no te van a pedir diseñar un sistema perfecto. Ese no es el objetivo.
Lo que realmente van a evaluar es la forma en la que piensas y abordas un problema muy ambiguo para llegar a una posible solución, colaborando con el entrevistador.
El objetivo debe ser partir de un problema abierto, establecer el alcance con el entrevistador y descomponerlo en partes más pequeñas y manejables.
El entrevistador va a querer comprobar si entiendes los problemas de los sistemas a gran escala. Una solución que puede ser perfectamente válida para un sistema con unos pocos miles de usuarios seguramente sea inviable para uno con decenas de millones de usuarios concurrentes.
Y ahí está la clave. El entender que no existe una solución perfecta y que todo en el desarrollo de software son trade-offs.
Cómo estructurar la entrevista
Con el tiempo tan limitado que tenemos, es muy importante estructurar bien la discusión. Aquí os dejo mi forma de abordar estas entrevistas y el tiempo en cada fase.
1. Toma de requisitos y definir el alcance (5-10 min)
En un problema tan abierto, podríamos estar hablando horas y horas de las distintas partes del sistema. Y no queremos perder el tiempo en áreas en las que el entrevistador no está interesado.
Mucha gente asume los requisitos y empieza a diseñar el sistema desde el principio, y eso es un gran error. Estas entrevistas hay que tomarlas como una discusión con el entrevistador, no como un problema que tienes que resolver por tu cuenta.
Para ello, debemos empezar definiendo los requisitos funcionales y no funcionales. Empieza con los requisitos más obvios y pregunta siempre al entrevistador si quiere aumentar el alcance por algún lado.
Por ejemplo, si tenemos que diseñar un sistema como YouTube, está claro que como mínimo debemos permitir subir y visualizar vídeos. Pero funcionalidades como comentarios, suscripciones, likes, etc. pueden estar dentro del alcance o no.
No podemos abarcar todo en tan poco tiempo, por lo que es probable que el entrevistador deje funcionalidades secundarias fuera del alcance. Pero, aunque eso pase, mencionarlas te da puntos a tu favor, ya que muestra que estás pensando a fondo sobre el problema.
2. Cálculos aproximados sobre la escala del sistema (5 min)
A partir de los requisitos, algunos entrevistadores estarán interesados en calcular ciertos datos sobre la escala del sistema. Por ejemplo, consultas por segundo (QPS), usuarios, almacenamiento necesario, etc.
Pregunta por datos como el número de escrituras por unidad de tiempo, el número de usuarios y haz los cálculos de forma aproximada. No tienen que ser exactos, es simplemente para dar una idea de la escala.
Es importante preguntar al entrevistador si está interesado en estos back-of-the-envelope calculations, ya que muchos, entre los que me incluyo, creemos que no aportan mucho valor y preferimos invertir más tiempo en discutir el diseño.
3. Diseño a alto nivel (15-20 min)
El siguiente paso es diseñar el sistema a alto nivel. No debemos entrar aún en detalle en ningún componente. Queremos establecer una primera solución al problema y ver que el entrevistador está conforme con ella.
Debes tratar el sistema end-to-end: clientes, APIs, servicios y almacenamiento de datos. Si necesita integraciones con servicios externos, menciónalo también. El objetivo es identificar los componentes del sistema y cómo interactúan entre ellos.
Algo muy importante es comentar los trade-offs de tus decisiones. En el desarrollo de software, una decisión que te ayuda a cumplir un objetivo tiene siempre sus contrapartidas. No hay una solución perfecta para todo, y debes dejar claro que lo tienes presente.
Asegúrate de que cubres todos los requisitos establecidos en la primera fase. Parece obvio, pero con la presión he visto muchos casos en los que uno se olvida de algún detalle y luego es complicado rectificar, por lo que no está de más comprobar de nuevo los requisitos.
4. Entrar en detalle en los componentes más importantes (15 min)
Una vez el entrevistador está conforme con el diseño a alto nivel, pasaremos a hablar a fondo de los componentes más importantes.
Esto depende mucho del problema en cuestión. Si diseñas un sistema como YouTube, deberías hablar del procesamiento de los vídeos; si te toca Uber, deberías hablar del algoritmo para emparejar conductores y pasajeros, etc.
En el hipotético caso de que no sepas de qué hablar, no tengas miedo de preguntarle al entrevistador para ver en qué está más interesado.
Otros temas que podrías tocar en esta fase si tienes tiempo son el diseño de datos, la estrategia de caching, el particionado de datos, la seguridad, las analíticas, las métricas y otros aspectos que no hayas cubierto aún en el diseño a alto nivel.
5. Cierre (5 min)
Aprovecha los últimos minutos de la entrevista para repasar el diseño y mencionar los temas más importantes.
También puedes hablar brevemente de temas que no hayas podido cubrir, para que el entrevistador sepa que no los has olvidado o ignorado, sino que no has tenido tiempo de tratarlos.
Puntos clave en el diseño de sistemas
Es difícil tratar los temas más importantes en estas entrevistas porque los problemas pueden ser muy distintos en cuanto a alcance y complejidad. Pero hay temas que sí o sí debes tener en cuenta en casi todos los diseños.
Escalabilidad. Diseña tu sistema para que pueda escalar horizontalmente (añadiendo más nodos). Para ello, prioriza los servicios stateless y utiliza componentes como load balancers y API gateways para distribuir la carga a tus servicios. Solo en casos muy concretos tiene sentido utilizar servicios stateful, como por ejemplo en sistemas en tiempo real que utilizan websockets.
Patrones de uso. Es el sistema read-heavy o write-heavy? Esto va a impactar mucho en tu diseño, sobre todo el acceso a datos y la caché, por lo que debes tenerlo en cuenta.
Caché. En cliente, usando un CDN, y en backend, usando Redis, por ejemplo. Considera las estrategias cache-aside (lazy loading), write-through (la caché siempre se actualiza en escrituras), write-back (escribes en la caché y luego la base de datos se actualiza), etc. Menciona también las estrategias de invalidación que seguirás.
Consistencia vs disponibilidad (teorema CAP). Considera los trade-offs de consistencia fuerte vs eventual. Por lo general, a gran escala suele ser preferible la consistencia eventual, pero depende del caso de uso. Hay casos, como sistemas de pagos o inventarios, donde se prioriza la consistencia.
Cubriendo bien esos puntos ya estás atacando la gran mayoría de problemas que suelen aparecer en entrevistas de diseño de sistemas.
Y recuerda, lo importante en estas entrevistas no es buscar la solución perfecta, porque no existe. Existe la solución adecuada para un contexto concreto.
Y si te interesa preparar este tipo de entrevistas de forma más guiada, recuerda echarle un vistazo a mi curso Diseño de Sistemas a Gran Escala y Arquitectura de Software, donde cubro toda la teoría, y 7 casos prácticos reales!
Muy interesante tu post, pero hay un tema sobre las concurrencias y proceso asincronos, como abordarias eso?