El lunes hice una ronda de diseño de sistemas para Forward-Deployed Engineer en Google, y no la pasé. Conocía los componentes — cachés, colas, particiones, balanceadores de carga. Lo que no hice, bajo presión, fue lo único que separa a un ingeniero de un arquitecto. Así que pasé la semana reconstruyendo la habilidad desde cero. Esto es lo que encontré, organizado de la forma en que hubiera querido saberlo antes de entrar.
Circula un post popular — "These 15 articles will turn you from engineer to architect" (Traducción: Estos 15 artículos te convertirán de ingeniero en arquitecto) — con enlaces al diseño de Instagram, la arquitectura de Netflix, el uso de caché, Kafka, y el resto. Son buenos artículos. Pero leer quince planos no te convierte en arquitecto, así como leer quince recetas no te convierte en chef. Los planos son el qué. La entrevista evalúa el cómo — y el cómo es un solo hábito.
El único hábito: nombra qué estás dispuesto a sacrificar
A un ingeniero le dicen "diseña Instagram" y recurre a una caja conocida, racionalizando hacia atrás. Un arquitecto se hace una primera pregunta distinta: ¿qué estoy dispuesto a sacrificar? Todo sistema real es una negociación entre cosas que no puedes tener por completo al mismo tiempo — y la más famosa tiene nombre.
CAP es toda la mentalidad en tres letras. Cuando la red se particiona (y a escala, sucederá), puedes conservar consistencia o disponibilidad para esos datos — nunca ambas. El saldo de un banco conserva la consistencia y rechaza la escritura; un contador de "me gusta" conserva la disponibilidad y concilia después. El arquitecto dice cuál está sacrificando en voz alta, y por qué. Esa frase — "for this data I'll trade consistency for availability because a stale like is fine but a rejected payment isn't" (Traducción: para estos datos cambiaré consistencia por disponibilidad, porque un 'me gusta' desactualizado no importa, pero un pago rechazado sí) — es el sonido del oficio.
Quince planos son el vocabulario. Las compensaciones son la gramática. No puedes hablar el idioma memorizando más palabras.
El loop del arquitecto: un método que puedes ejecutar bajo presión
Este fue el error que realmente cometí: salté directo a cajas y flechas antes de establecer los números que hacen que una arquitectura sea correcta y otra un desperdicio. Así que convertí el hábito en un loop de cinco pasos que puedo ejecutar en voz alta en cualquier entrevista. También funciona como esquema para cualquier respuesta.
El loop del arquitecto. Los pasos en azul son donde antes yo saltaba directo a Sketch. La entrevista te evalúa en Constrain, Estimate, Stress y Evolve —las partes que muestran criterio, no memoria.
La magia está en el paso 2. Los números a grosso modo condicionan cada decisión posterior. Usuarios activos diarios × acciones × payload = tu QPS de escritura. Las lecturas suelen ser 10–1000× las escrituras. El almacenamiento es datos-por-día × retención. Sin eso no puedes justificar una caché, una cantidad de particiones o una cola —solo puedes adivinar, y un entrevistador huele cuando adivinas. Con esos números, una arquitectura se vuelve obviamente correcta y otra obviamente un desperdicio, y puedes explicar por qué.
El vocabulario, reagrupado según la decisión que resuelve
Ahora los quince temas dejan de ser una lista de lectura y se convierten en cuatro grupos de decisiones. En cada uno, lo único que vale la pena memorizar es la llamada no obvia —esa que un ingeniero inteligente resuelve mal.
Grupo 1 — el plano de datos (dónde vive el estado)
| Tema | La decisión no obvia |
|---|---|
| Elección de base de datos | Elige según el patrón de acceso, no la moda: primero modela la consulta más frecuente, luego elige el almacén que la haga O(1). SQL para ACID + relaciones; columnas anchas para feeds de escritura masiva; la clave de partición existe para mantener la consulta más frecuente en una sola partición. |
| Caché | Lo difícil no es la velocidad, es la invalidación. El TTL es la opción pragmática por defecto; la trampa es la thundering herd en una clave fría o expirada — se soluciona con coalescencia de solicitudes y stale-while-revalidate (revalidación en segundo plano)cache-aside; esa es la política de escritura habitual. |
| Estructuras de datos | Se corresponden con el medio de almacenamiento: los B-trees minimizan los accesos a disco (índices SQL); los LSM-trees favorecen las escrituras (Cassandra); los anillos de hashing consistente mueven la mínima cantidad de datos cuando un nodo entra o sale; los bloom filters evitan a bajo costo búsquedas que de todos modos fallarían. |
Grupo 2 — la puerta de entrada y el contrato
| Tema | La decisión no obvia |
|---|---|
| Balanceador de carga vs. proxy inverso | Son preguntas distintas. El balanceador de carga responde a "demasiado tráfico para un solo servidor" (distribuye la carga entre backends idénticos). El proxy inverso responde a "necesito una puerta de entrada inteligente" (TLS, ruteo, amortiguar clientes lentos antes de que lleguen a la app) — y puede servir a un solo servicio. La mayoría de las puertas de entrada hacen ambas cosas. |
| REST / APIs | La ausencia de estado es la clave: cada solicitud lleva su propio contexto, así que cualquier servidor puede atenderla — la propiedad que te permite escalar horizontalmente detrás de un balanceador de carga. La idempotencia es lo que hace que los reintentos sean seguros en un sistema distribuido. Recurre a gRPC (interno, baja latencia, streaming) o GraphQL (payloads a medida del cliente) cuando la uniformidad de REST te sale cara. |
Grupo 3 — la columna vertebral asíncrona (desacoplar en el tiempo)
| Tema | La decisión no obvia |
|---|---|
| Kafka / colas | Un registro reproducible desacopla a productores y consumidores en tiempo y ritmo. El orden es por partición, no global — elige la clave de partición para preservar el orden que realmente necesitas. Tu métrica de salud real es el retraso de consumidores, no el rendimiento. |
| Microservicios | La causa es organizacional, no técnica (la ley de Conway — equipos que despliegan de forma independiente). Cambias una llamada en proceso por un salto de red que puede fallar; a cambio, ganas descubrimiento de servicios, reintentos, circuit breakers, trazabilidad y sagas en lugar de transacciones distribuidas. Verdad contraria a la intuición: la mayoría de los sistemas deberían empezar como un monolito bien estructurado. |
| Patrones arquitectónicos | Cada uno cambia acoplamiento por flexibilidad, o consistencia por escala: dirigido por eventos (desacoplado, eventualmente consistente), CQRS (separa los modelos de lectura/escritura cuando sus cargas divergen), strangler-fig (migra un monolito de forma incremental). Nombrar el patrón no es la habilidad — saber qué restricción alivia sí lo es. |
Grupo 4 — los dos casos de estudio (donde una estrategia uniforme se rompe)
Instagram y Netflix son famosos porque cada uno enseña una lección precisa sobre la cola de una distribución.
Instagram = fan-out híbrido. Una estrategia uniforme se rompe en la cola: el empuje da lecturas O(1) pero explota con las celebridades; la extracción es barata para escribir pero lenta para leer. La respuesta es ambas, elegidas según la cuenta. Detectar cuándo una regla uniforme falla en la cola es toda la prueba.
Netflix enseña la división opuesta: separar el plano de datos masivo y cacheable (video pre-codificado en múltiples bitrates, empujado a los bordes de CDN cerca de los ISP) del plano de control pequeño y dinámico (auth, recomendaciones — microservicios en la nube). Y trata la falla como algo normal: la ingeniería del caos mata instancias deliberadamente para probar que el sistema sobrevive. La conclusión del arquitecto — diseña para la falla como caso habitual, y acerca los bytes a los usuarios.
El movimiento final que olvidé hacer
Esto es lo que ahora hago y que no hice el lunes. Después del boceto del camino feliz, recorro los modos de falla en voz alta: ¿qué pasa cuando este nodo muere, esta cola se satura, este caché se enfría, este shard se sobrecalienta? Luego nombro el cuello de botella y el siguiente recurso de escalamiento. Un diseño sin su historia de fallas es una respuesta de ingeniero. Nombrar el cuello de botella y cómo evolucionarías más allá de él: eso es lo del arquitecto, y es la parte que se evalúa.
Todo el método en un respiro
Restringe el problema, estima los números, bosqueja el camino que esos números exigen, somete a estrés ante la falla, y evoluciona — nombrando el cuello de botella y la siguiente palanca. Declara cada compensación en voz alta. Eso es todo. Esa es la diferencia entre conocer los quince artículos y ser la persona que puede diseñar el decimosexto.
Reprobé una ronda de diseño de sistemas el lunes. Para el viernes se había convertido en un marco de trabajo — y, honestamente, entiendo este material mejor ahora que si hubiera aprobado. Convertir el fracaso en algo que pudiera enseñar es lo que hizo que se me quedara grabado. Si tú también te estás preparando: no leas los quince artículos buscando las respuestas. Léelos por las compensaciones, y practica decir cuál estás eligiendo, en voz alta, cada vez.
Escrito después de una ronda de diseño de sistemas para Forward-Deployed Engineer en Google que no pasé, digiriendo la lista de lectura "15 articles, engineer → architect" (Traducción: "15 artículos, de ingeniero a arquitecto") hasta llegar al único hábito que subyace en todos ellos. Si te ayuda a entrar más tranquilo de lo que entré yo, cumplió su propósito. — Paul