Diseñar un sistema en cuarenta minutos
No se espera que salga la arquitectura correcta: se espera que hagas las preguntas correctas, propongas algo simple y sepas explicar qué se rompe cuando crece. El error más común es empezar a dibujar cajas antes de saber qué se está construyendo.
«Diseñá un acortador de URLs.» La reacción habitual es empezar a dibujar: un balanceador, unos servidores, una base, un caché. A los diez minutos hay un diagrama lleno y nadie preguntó cuánta gente lo va a usar ni qué tiene que garantizar.
En estas entrevistas el diagrama es lo último que importa. Lo que se evalúa es si podés convertir un enunciado vago en requisitos, elegir lo más simple que los cumpla, y explicar qué se rompe primero cuando la escala cambia.
Los cinco tramos
Cómo repartir cuarenta minutos
- Requisitos, 5 a 8 minutos. Qué tiene que hacer, qué no, y qué garantiza. Quién lo usa y para qué.
- Escala, 3 a 5 minutos. Usuarios, lecturas y escrituras por segundo, tamaño de los datos, crecimiento. Números aproximados dichos en voz alta.
- Diseño simple, 10 minutos. La versión más chica que cumple los requisitos. Componentes, modelo de datos, el camino de un pedido de punta a punta.
- Escalar y romper, 10 a 15 minutos. Qué se cae primero con diez veces más carga y cómo se resuelve. Acá está la mayor parte del puntaje.
- Cierre, 3 minutos. Qué quedó sin resolver, qué monitorearías, qué harías distinto con más tiempo.
Las preguntas que hay que hacer
| Dimensión | Qué preguntar | Por qué cambia el diseño |
|---|---|---|
| Uso | ¿Se lee mucho más de lo que se escribe? | Define si la solución pasa por caché y réplicas de lectura |
| Escala | ¿Cuántos usuarios, cuántas operaciones por segundo? | Miles y millones piden diseños distintos; asumir mal arruina todo |
| Consistencia | ¿Puede haber unos segundos de desfasaje? | Es la decisión que más cambia la arquitectura |
| Latencia | ¿Cuánto puede tardar? | Define si algo puede ser asincrónico |
| Durabilidad | ¿Qué pasa si se pierde un dato? | No es lo mismo un like que una transferencia |
| Alcance | ¿Incluye estadísticas, cuentas, permisos? | Evita diseñar tres sistemas en cuarenta minutos |
Antes de seguir, predecí
Empezar simple es la señal de experiencia
| Señal de inexperiencia | Señal de experiencia |
|---|---|
| Empezar con microservicios y colas | Empezar con una aplicación y una base, y justificar cada pieza que se agrega |
| Nombrar tecnologías de moda | Nombrar propiedades: «necesito algo que garantice orden por clave» |
| Diseñar para mil millones de usuarios | Diseñar para la escala que se acordó, y decir qué cambiaría diez veces más arriba |
| Evitar las debilidades del diseño | Señalar los puntos únicos de falla y qué haría con más tiempo |
Dónde está la mayor parte del puntaje
El tramo de escalar es donde más se diferencia una entrevista buena de una regular. La secuencia que conviene seguir:
Multiplicá la carga por diez y preguntate
- ¿Qué se satura primero? Casi siempre la base de datos: conexiones, escrituras, consultas lentas.
- ¿Qué es lo más barato que lo alivia? Caché de lo más leído, índices, réplicas de lectura. En ese orden, antes de rediseñar nada.
- ¿Qué se puede hacer asincrónico? Todo lo que el usuario no necesita esperar: correos, estadísticas, procesamiento de imágenes.
- ¿Dónde hay un punto único de falla? Y qué pasaría si se cae.
- ¿Qué se rompe a la siguiente multiplicación por diez? Ahí aparecen particionamiento y separación por dominio, y ahí sí se justifican.
Los primeros diez minutos
Escenario · 1 decisión como mínimo
«Diseñá un acortador de URLs» — y tenés cuarenta minutos
Te dan el enunciado y una pizarra en blanco. Ya tenés en la cabeza el diagrama completo: balanceador, servicio, base, caché. ¿Qué hacés con los primeros minutos?
A los diez minutos el diagrama está lleno. Te preguntan cuántas lecturas por segundo tiene que aguantar.
DesenlaceNo lo sabés, porque no lo preguntaste, y ahora cada caja del diagrama está sin justificar. El diagrama es lo último que importa: es la consecuencia de los requisitos, no el punto de partida.
Te contestan «la que te parezca» y quedan esperando.
DesenlaceLa respuesta te devolvió la pregunta, porque era la pregunta equivocada. La elección de base sale de los requisitos: si no los tenés, cualquier respuesta es una preferencia personal.
Preguntás y te contestan: 100 millones de links creados por mes, lecturas 100 a 1 sobre escrituras, los links no se borran, y hace falta saber cuántas veces se usó cada uno. ¿Qué hacés con eso?
Proponés un caché. Te preguntan por qué.
DesenlaceLa respuesta buena era «porque 100 a 1 de lecturas sobre escrituras significa cuarenta mil lecturas por segundo en pico, y eso no lo sostiene la base sola». Sin la cuenta, queda en «porque siempre se pone un caché».
Sacás 40 escrituras por segundo, unas 4000 lecturas, y unos 600 GB a cinco años. Con eso, ¿por dónde arrancás el diseño?
Te preguntan qué gana el particionamiento con 40 escrituras por segundo.
DesenlaceNo gana nada, y cuesta bastante. Proponer complejidad que los requisitos no piden es peor que proponer de menos: muestra que el diseño no salió de los números que acabás de calcular.
Tenés el diseño simple en la pizarra y quedan veinte minutos. Te preguntan: «¿y si el tráfico se multiplica por cien?».
Aceptan y repreguntan: «¿y qué se rompe después de eso?».
DesenlaceVan a seguir empujando hasta encontrar el límite del diseño, porque eso es lo que se está evaluando. Conviene llegar primero: nombrar el cuello de botella antes de que te lo señalen.
Decís que a 400 mil lecturas por segundo el problema no es la base sino la red hacia el caché, que la generación de códigos únicos se vuelve un punto de contención, y proponés códigos pregenerados por rango.
DesenlaceEso es exactamente lo que se busca: convertir un enunciado vago en números, elegir lo mínimo que los cumpla y saber dónde se rompe. El diagrama final quedó igual de simple que a los quince minutos, y la conversación de los últimos veinte fue la entrevista entera.
Mirá en qué paso aparece el primer dibujo. Es mucho más tarde de lo que parece.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica