Nadie te pregunta qué es un load balancer
Notas do episódio
En una entrevista de diseño de sistemas nadie te pregunta “¿qué es un load balancer?”. Te dan un problema abierto tipo “diseñá Instagram” y te miran los primeros dos minutos. Ahí se nota quién sabe términos y quién sabe diseñar.
La mayoría estudia diseño de sistemas memorizando piezas sueltas, load balancer, cache, CAP theorem, y por eso se queda en blanco frente a un problema abierto.
Y esto se ve reflejado en una entrevista de 40 minutos, diseñando un sistema real, o evaluando qué decisión tomó por vos un agente de IA cuando le pedís una arquitectura.
💡 Cuatro etapas, siempre en el mismo orden
Alex Xu describe cuatro etapas en el diseño de sistemas, en System Design Interview, un libro de referencia del tema. Las etapas son: entender el problema, proponer un diseño de alto nivel, profundizar donde importa, y concluir.
Etapa 1 — Entender el problema y el alcance. Antes de dibujar nada, hay que preguntar: ¿qué tiene que hacer el sistema? ¿Bajo qué condiciones? Un dato que cambia el diseño entero y casi nadie pregunta: ¿los usuarios leen mucho más de lo que escriben, o al revés? Netflix mostrando el mismo capítulo a millones de personas es un problema de fan-out, distribuir lo mismo a mucha gente sin que el origen colapse. Un generador de imágenes con IA recibiendo millones de prompts a la vez es fan-in, absorber volumen sin que el sistema se caiga. Son dos problemas distintos con dos soluciones distintas.
Etapa 2 — Diseño de alto nivel y acuerdo. Ahora sí empezás a dibujar, pero en bloques grandes: cliente, load balancer, servicio, base de datos. Sin profundizar en ninguno todavía. El objetivo es recorrer uno o dos casos de uso reales con la otra persona (entrevistador o stakeholder) y confirmar que el mapa cubre lo que se pidió, es una conversación, no un monólogo.
Etapa 3 — Deep dive. Con el mapa completo, elegís las tecnologías que importan para ESE problema. Por ejemplo, si el sistema lee mucho más de lo que escribe, profundizás en cache y réplicas. Si escribe mucho y necesita orden, profundizás en particionado y colas. Si hay una base de datos tipo DynamoDB, acá definís la clave de partición y la estructura de las tablas.
Etapa 4 — Concluir. La etapa que más gente ni llega a pisar, porque se quedó atascada antes. Acá hablás de cuellos de botella, casos de error, y cómo escalarías si hiciera falta. No es un cierre protocolar, es donde demostrás que ves el sistema completo, no solo la pieza que más te gustó dibujar.
🤖 Por qué esto importa todavía más con IA
Hoy le podés pedir a un agente que te arme una arquitectura en 10 segundos. El agente sabe cómo armar ese diagrama. No sabe por qué tu caso necesita lo que eligió, o si eso que armó aguanta tu escala real.
Ese “por qué” sigue siendo tuyo. Y es exactamente este proceso, las 4 etapas, el que te permite evaluar si lo que armó el agente tiene sentido, o hacerle las preguntas correctas para que termine de armar la arquitectura completa.
De eso justamente voy a hablar en una clase en vivo y gratuita el miércoles 7 de octubre: diseño de sistemas en la era de la IA, vamos a ver que es spec-driven development y Kiro y como nos puede ayudar.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com