Como siempre lo digo en mis charlas o en clase: me ha tocado estar en ambos lados de la mesa, tanto como entrevistador como entrevistado, así que hoy te traigo un artículo basado en mi experiencia. ¡Arranquemos!

En las entrevistas de diseño de sistemas para roles de alta jerarquía (Senior, Staff o Architect), el reto clásico de "Diseña un sistema como Twitter/X para 100 millones de usuarios" a menudo se aborda con un enfoque erróneo: el "diseño por catálogo". Esto consiste en rellenar la pizarra con cajas de moda, o sea, los balanceadores, cachés, colas y bases de datos NoSQL... como si fueran piezas de Lego que encajan mágicamente sin coste alguno.

Sin embargo, una arquitectura distribuida no es inherentemente mejor que una centralizada; simplemente intercambia un tipo de problemas por otro. En el mundo real, no existen las soluciones perfectas, solo los compromisos (trade-offs). Un arquitecto senior no defiende un diagrama por su complejidad, sino por su viabilidad ante las restricciones físicas del hardware, la red y el presupuesto operativo.

La brecha entre las flechas de la pizarra y los fierros de producción

En la pizarra, las flechas que conectan tus servicios representan flujos lógicos de datos. En producción, esas mismas flechas se traducen en llamadas de red, buffers de memoria, sockets TCP abiertos y bytes que deben serializarse y viajar por un cable.

Cuando distribuimos un sistema de forma prematura o sin medir el impacto, solemos pasar por alto realidades operativas críticas:

• La ilusión de la disponibilidad matemática: Imagina que una petición necesita pasar por tres microservicios y que cada uno tiene una disponibilidad del 99.9 %. Una forma sencilla de estimar la disponibilidad del flujo completo es multiplicar esas probabilidades (99.9 % × 99.9 % × 99.9 %), lo que da aproximadamente un 99.7 %. La idea no es memorizar la fórmula, sino entender que cada dependencia síncrona adicional puede reducir la disponibilidad del sistema. Eso sí, esta es solo una aproximación que asume que los fallos son independientes y que todos los servicios son imprescindibles para responder. En producción, el comportamiento real dependerá de factores como las políticas de reintentos (retries), los backoffs exponenciales, los circuit breakers, las cachés o las estrategias de degradación elegante (graceful degradation). Cuando estas dependencias no se gestionan correctamente, un fallo puntual puede propagarse y desencadenar un efecto dominó que termine saturando servicios que originalmente estaban sanos.
• El verdadero dilema de los datos: El teorema CAP sigue siendo el punto de partida para entender los sistemas distribuidos: cuando ocurre una partición de red, debes elegir entre consistencia o disponibilidad. Sin embargo, muchas decisiones de arquitectura del día a día se explican mejor con el teorema PACELC, que amplía esa idea al recordar que, incluso cuando no existen particiones de red, sigue habiendo un compromiso entre Latencia y Consistencia. Por ejemplo, si replicas datos entre LATAM y Europa para reducir los tiempos de lectura, en muchos casos tendrás que aceptar consistencia eventual para evitar que cada escritura espere la confirmación de todos los nodos.

En este artículo te hablo del teorema CAP 😉

Validando la escala con números reales (y sus trampas)

Ahora imaginemos que hacemos unos cálculos rápidos en la pizarra para esos 100 millones de usuarios activos. Si asumimos que generan un promedio de 2 publicaciones al día, tendríamos unas 2,315 peticiones de escritura por segundo (RPS). Si cada payload pesa unos 5 KB, la ingesta neta de datos es de aproximadamente 11.5 MB/s.

Cualquiera podría concluir a la ligera: "11.5 MB/s los soporta un único nodo moderno en ancho de banda". Pero esa es una verdad a medias. En producción, el rendimiento real dependerá de la naturaleza de la carga: ¿Son escrituras secuenciales en un log o escrituras aleatorias que destrozan los índices de la base de datos? ¿Cómo impacta eso en las IOPS (operaciones de entrada/salida) del disco? Ajá dev, ves que allí cambia la cosa?

Y el escenario se complica de verdad cuando pasamos a las lecturas (el Fan-out). Si cada usuario sigue a un promedio de 200 personas, una sola escritura puede llegar a amplificarse en miles de operaciones de lectura para actualizar los timelines de sus seguidores. Aquí es donde la pizarra se vuelve indispensable para evaluar alternativas:

Una opción común para mitigar este cuello de botella en las lecturas es usar un enfoque asíncrono. Sin embargo, la herramienta elegida cambiará por completo tu modelo operativo. Por ejemplo, si usas RabbitMQ, dependerás de un sistema de mensajería tradicional basado en colas inteligentes que rastrean el estado de cada mensaje (ideal si necesitas enrutamiento complejo o lógica de trabajo pesada).

Si por otro lado quieres sonar más fancy (bromita) y optas por Kafka, estarás introduciendo un log de eventos distribuido, donde los mensajes son persistentes y son los consumidores quienes gestionan su propia posición (perfecto si buscas procesar flujos de datos a gran escala y permitir que múltiples servicios reexaminen el historial).

Lecciones del barro: Los problemas que no salen en los libros

Un entrevistador senior suele darse cuenta de cuándo alguien ha trabajado con sistemas reales. La diferencia aparece cuando dejas de hablar solo del diagrama y empiezas a mencionar los problemas que, tarde o temprano, terminan apareciendo en producción.

La partición caliente (Hot Partition): Diseñas una base de datos distribuida y decides repartir los datos por User_Id. Al principio todo funciona perfectamente porque la carga está bastante equilibrada. Pero un día una celebridad con millones de seguidores publica algo y ese usuario empieza a generar muchísimo más tráfico que el resto. De repente, un solo shard o una parte del sistema recibe mucha más carga que las demás. Es un problema muy común cuando la distribución de los datos parece buena sobre el papel, pero algunos usuarios tienen un comportamiento muy diferente al promedio. En estos casos, suele ser necesario tratar a esos usuarios de forma distinta para evitar que se conviertan en un cuello de botella.

La avalancha sobre la base de datos (Cache Stampede): Añades una caché para evitar consultar constantemente la base de datos y todo va bien... hasta que expira un dato muy solicitado. En ese instante, miles de peticiones intentan obtener el mismo dato al mismo tiempo y todas terminan consultando la base de datos (Thundering Herd Problem). Si no has preparado el sistema para ese escenario, un simple vencimiento de la caché puede terminar saturando la base de datos. Por eso es habitual implementar mecanismos para que solo una petición regenere la información mientras las demás esperan o reutilizan el resultado.

La tormenta de reintentos (Retry Storm): Un servicio empieza a responder más lento de lo normal. Como los demás servicios están configurados para reintentar automáticamente, comienzan a enviar todavía más peticiones justo cuando el sistema está más sobrecargado. Lo que empezó como un pequeño problema de latencia acaba convirtiéndose en una caída mucho mayor. Los reintentos son una excelente herramienta de resiliencia,pero si no se configuran correctamente también pueden empeorar el problema que intentan solucionar.

En conclusión...

Así que ya sabes, estimado dev, la pizarra es una herramienta brutal de comunicación e ingeniería, pero cobra valor real cuando dejas espacio para la incertidumbre. En tu próxima entrevista, no intentes vender un diseño infalible de manual. Demuestra que sabes medir los límites del hardware, que entiendes las implicaciones de red de cada flecha que dibujas y que eres consciente de que, al final del día, operar un sistema a gran escala consiste en decidir qué problemas prefieres gestionar cuando las cosas salgan mal, y, por supuesto, disfrutar cuando salgan bien. Eso es lo que te hace un verdadero ingeniero.

Si este artículo te ha encantado, compártelo con todo tu team!

Créditos de imagen de portada: Foto de ThisisEngineering en Unsplash