Qué es de verdad el diseño de sistemas: de un servidor a millones de usuarios

Imagina una aplicación para compartir fotos: te registras, subes fotos, sigues a otros y recorres un hilo de imágenes. Escribes el código, lo despliegas todo en un solo servidor y funciona a la perfección; una máquina basta para los primeros miles de usuarios y guarda todos sus datos. Luego 10 millones de personas abren la aplicación cada día y, aunque el código de subida apenas cambia, los problemas a resolver son otros: dónde guardar cientos de terabytes de fotos, qué pasa si el servidor se cae, cómo mantener rápido el hilo para un usuario en India cuando el servidor está en Estados Unidos, y qué ocurre cuando una cuenta popular publica una foto que un millón de personas quiere ver a la vez. Ya no son problemas de una sola función, sino del diseño conjunto y de la cooperación de sus partes.

El diseño de sistemas es el proceso que decide qué componentes necesita un sistema, de qué es responsable cada uno, cómo se comunican y cómo fluyen los datos entre ellos, para que el sistema cumpla sus requisitos. Opera un nivel por encima del código: donde el código piensa en funciones , clases , estructuras de datos y algoritmos, el diseño piensa en servidores , bases de datos , cachés , colas, almacenamiento y red. También integra qué pasa cuando un componente se frena o falla y cómo cambia el comportamiento cuando el tráfico y los datos crecen.

Requisitos: qué hace y con qué calidad

Todo diseño empieza por los requisitos, porque no se puede juzgar un dibujo sin saber qué debe hacer el sistema. Forman dos grupos: los requisitos funcionales dicen qué debe hacer el sistema, como subir fotos, seguir usuarios, marcar me gusta y ver el hilo; los no funcionales dicen con qué calidad, como un hilo visible en menos de 200 milisegundos, una aplicación alcanzable aunque caiga un servidor y fotos subidas jamás perdidas. Los primeros deciden funcionalidades, API y componentes; los segundos moldean su dibujo, la capacidad necesaria y el trato de los fallos. Según Educative, esta distinción es el plano de todas las decisiones posteriores: una aplicación para cien usuarios puede compartir cada función con la que sirve a cien millones estando diseñada de forma muy distinta.

La mayoría de los grandes sistemas nace de un conjunto pequeño de piezas comunes. Los clientes como móviles y navegadores envían las peticiones, el DNS traduce el dominio a dirección de servidor, el balanceador reparte el tráfico entre servidores de aplicación que ejecutan la lógica de negocio. Las bases guardan datos estructurados como usuarios, seguimientos y metadatos de fotos, mientras el almacén de objetos guarda las fotos mismas; la caché mantiene en memoria las lecturas frecuentes para aliviar la base, la CDN acerca copias del contenido estático a los usuarios y las colas de mensajes pasan el trabajo no urgente al fondo para no hacer esperar. Gran parte del oficio es elegir las piezas útiles y su cooperación. El mapa de piezas de Mehdi Akiki propone leer cada pieza en cuatro preguntas: qué es, por qué existe, cuándo aparece y qué se rompe con el abuso; la caché existe porque las lecturas repetidas cuestan caro, la cola porque no todo debe pasar por la vía de petición, la CDN porque los usuarios están lejos de los servidores.

De extremo a extremo: el viaje de una foto

Veamos estas piezas juntas en la aplicación. Cuando un usuario sube una foto, la petición cruza el balanceador hacia uno de los servidores de aplicación; el servidor escribe en la base los metadatos como autor, descripción y marca temporal, y luego produce una URL prefirmada que autoriza a la app a subir la imagen directa al almacén de objetos. Terminada la subida, el sistema deja un trabajo en una cola para el proceso complementario, y las tareas de fondo lo toman, como generar miniaturas o actualizar los hilos de seguidores. La lección de CodeSnatch sobre almacén de objetos y CDN confirma el modelo: según CodeSnatch, las bases son el mal domicilio de los grandes ficheros sin estructura, los almacenes tipo S3 ofrecen espacio barato y sin límite con once nueves de durabilidad, y las URL prefirmadas dejan al cliente escribir directo al almacén.

La lectura emplea las mismas cajas de otro modo. Cuando otro usuario abre su hilo, el servidor de aplicación consulta primero la caché para la lista de publicaciones; si falta, lee la base y guarda el resultado en caché para las peticiones siguientes. Las imágenes mismas llegan por la CDN, desde un servidor cercano al lugar del usuario en vez del depósito de origen cada vez. Cada componente tiene su razón: la CDN reduce la latencia, la cola aparta lo lento de la vía de petición, la caché alivia la base y el almacén de objetos ofrece un sitio que crece para los grandes ficheros.

Calidades y equilibrios

Para juzgar un dibujo se miran calidades conocidas: la escalabilidad , absorber más usuarios, tráfico y datos cuando la demanda crece ; la disponibilidad , seguir alcanzable cuando hace falta aunque caigan componentes ; la fiabilidad , comportarse bien sin perder, duplicar ni corromper datos ; el rendimiento , medido en latencia, lo que tarda una petición, y en caudal, las peticiones servidas en un periodo ; la coherencia , ver todos la misma vista actual de los datos ; la mantenibilidad , explotar, depurar, actualizar y extender sin pena ; y por fin el coste , porque un buen dibujo cumple sus requisitos sin gastar más servidores, almacén, banda ni esfuerzo del que hace falta.

Mejorar una de estas calidades suele pagarse en otra parte. Añadir caché alivia la base y acelera mucho las lecturas, pero los datos en caché pueden ranciarse y quedar caducados hasta el refresco o la expiración. Más réplicas y redundancia pueden levantar rendimiento y disponibilidad, pero suben el coste y complican la explotación. Apenas existe un dibujo mejor en todo ; gran parte del oficio es entender estos equilibrios , decidir qué calidades importan para sus requisitos y saber explicar por qué tal enfoque vence a tal otro.

Empieza pequeño, crece en cuellos, narra en la entrevista

Los sistemas reales rara vez nacen en su forma final. La app de fotos puede empezar con un solo servidor de aplicación y una sola base, de sobra para los primeros miles de usuarios. Cuando el uso crece, aparecen cuellos distintos: la base se satura, servir imágenes se frena, el trabajo de fondo retrasa las peticiones ; entonces se añade el componente que resuelve el problema preciso, caché, CDN, réplicas de lectura o cola. Añadirlo todo demasiado pronto crea sobre todo complejidad, depuración y coste sin gran valor. Un buen dibujo cumple las exigencias del día guardando sitio para la escala de mañana.

Quien trabaja en el dorsal toma sin cesar decisiones de diseño, aun en funciones pequeñas. Tomemos el botón de me gusta : ¿cachear el contador, debe la actualización pasar en síncrono en la petición o ir a una cola para proceso de fondo, y qué pasa si el tráfico explota porque una celebridad atrae millones de interacciones. Conocer el diseño ayuda a razonar estas opciones, a ver los equilibrios y a explicar por qué un enfoque tiene más sentido que otro.

El diseño también pesa en las entrevistas de contratación. En muchas tecnológicas, una vuelta de diseño de sistemas es estándar para ingenieros medios y seniors, y algunas ofrecen una versión simple a los menos expertos. El desempeño puede influir en el nivel de entrada, luego directo en el salario. El formato suele ser abierto : unos 45 minutos a una hora para tratar un tema como un acortador de enlaces, un chat o una app de fotos como la del vídeo ; no hay respuesta única y no se espera código que pase pruebas. Se sigue más bien un proceso cercano al del vídeo : aclarar requisitos, estimar la escala, esbozar un dibujo de alto nivel, luego cavar en zonas clave como la base, la caché, los flujos de datos y la gestión de fallos, explicando decisiones y equilibrios al pasar. La guía 2026 de TryExponent nota que la vuelta se gana ya en coste, modos de fallo y juicio de explotación ; el marco de siete pasos de InterviewLoop recomienda el mismo orden : aclarar, estimar, dibujar, cavar, explicar equilibrios. La lección común : inútil memorizar los dibujos corrientes, porque quien entiende las piezas base, los problemas que resuelven y los costes que traen puede razonar sobre sistemas jamás vistos.