Fundamentos del Diseño de Sistemas

¿Qué Es el Diseño de Sistemas?

El diseño de sistemas es el proceso de definir la arquitectura, componentes, módulos, interfaces y flujos de datos de un sistema para satisfacer requisitos especificados. Se encuentra en la intersección de la ingeniería de software y la ingeniería de infraestructura, requiriendo que pienses en cómo las piezas individuales de software trabajan juntas a escala para entregar un producto confiable y de alto rendimiento.

Ya sea que estés construyendo un acortador de URLs que maneja unos pocos miles de solicitudes por día o un feed de redes sociales que sirve a miles de millones de usuarios, el pensamiento de diseño de sistemas te ayuda a tomar decisiones informadas de compensación que mantienen tu sistema funcionando sin problemas a medida que crece la demanda.

Conceptos Fundamentales del Diseño de Sistemas

Antes de sumergirte en patrones y tecnologías específicas, necesitas una comprensión sólida de las propiedades fundamentales que todo sistema distribuido debe esforzarse por lograr. Estos son los pilares contra los cuales se evalúa cada decisión de diseño.

1. Escalabilidad

La escalabilidad es la capacidad de un sistema para manejar una cantidad creciente de trabajo agregando recursos. Un sistema escalable puede acomodar una mayor demanda sin cambios significativos en su arquitectura.

• Escalado Vertical (Scale Up): Agregar más CPU, RAM o almacenamiento a una máquina existente. Simple pero limitado por los techos del hardware.
• Escalado Horizontal (Scale Out): Agregar más máquinas para distribuir la carga. Más complejo pero virtualmente ilimitado y más tolerante a fallos.

La idea clave es que el escalado horizontal casi siempre se prefiere para sistemas a gran escala porque ninguna máquina individual, por poderosa que sea, puede manejar el tráfico de servicios como Netflix o Google.

2. Fiabilidad

Un sistema fiable continúa funcionando correctamente incluso cuando los componentes fallan. En sistemas distribuidos, los fallos no son excepciones — son la norma. Los discos duros fallan, los paquetes de red se pierden y centros de datos enteros pueden quedar fuera de línea. Un sistema fiable está diseñado para tolerar estos fallos sin perder datos o volverse inaccesible.

Las técnicas para mejorar la fiabilidad incluyen redundancia (ejecutar múltiples copias de servicios), replicación (mantener copias de datos en múltiples ubicaciones) y aislamiento de fallos (asegurar que un fallo en un componente no se propague a otros).

3. Disponibilidad

La disponibilidad mide la proporción del tiempo que un sistema está operativo y accesible. Típicamente se expresa como un porcentaje, a menudo referido como "nueves" de disponibilidad.

Pasar de tres nueves a cuatro nueves es dramáticamente más difícil y costoso que ir de dos nueves a tres. Cada nueve adicional típicamente requiere una inversión significativa en ingeniería de redundancia, monitoreo y conmutación automática por error.

4. Mantenibilidad

La mantenibilidad abarca lo fácil que es corregir errores, agregar nuevas funcionalidades y operar el sistema día a día. Un sistema mantenible tiene abstracciones limpias, buena documentación, monitoreo integral y pipelines de despliegue automatizados.

Los tres aspectos de la mantenibilidad son operabilidad (hacer fácil para los equipos de operaciones mantener el sistema funcionando), simplicidad (eliminar complejidad innecesaria para que nuevos ingenieros puedan entender el sistema) y evolucionabilidad (hacer fácil cambiar el sistema a medida que evolucionan los requisitos).

5. Latencia y Rendimiento

La latencia es el tiempo que tarda una sola solicitud en viajar del cliente al servidor y de vuelta. El rendimiento es el número de solicitudes u operaciones que un sistema puede manejar por unidad de tiempo. Estas dos métricas a menudo tienen una relación inversa — optimizar una puede perjudicar la otra.

Marco para Entrevistas de Diseño de Sistemas

Las entrevistas de diseño de sistemas evalúan tu capacidad para diseñar sistemas a gran escala bajo ambigüedad. Tener un marco estructurado te ayuda a mantenerte organizado y cubrir todos los aspectos críticos dentro del límite de tiempo (típicamente 35-45 minutos).

Paso 1: Clarificar Requisitos (5 minutos)

Nunca saltes directamente a la solución. Comienza haciendo preguntas para entender el alcance. Hay dos tipos de requisitos a identificar:

• Requisitos Funcionales: ¿Qué debe hacer el sistema? ¿Cuáles son las funcionalidades principales? Por ejemplo, para un acortador de URLs: crear URLs cortas, redirigir a URLs originales, alias personalizados, analíticas.
• Requisitos No Funcionales: ¿Cómo debe rendir el sistema? Esto incluye objetivos de latencia, requisitos de disponibilidad, necesidades de consistencia y escala esperada.

Paso 2: Estimar la Escala (3 minutos)

Los cálculos aproximados te ayudan a entender el orden de magnitud con el que estás lidiando. Números clave a estimar:

• Usuarios activos diarios (DAU)
• Ratio de lectura a escritura
• Consultas por segundo (QPS)
• Requisitos de almacenamiento a lo largo del tiempo
• Necesidades de ancho de banda

// Ejemplo: Estimando escala para un acortador de URLs
// Suposiciones:
// - 100 millones de URLs creadas por mes
// - Ratio Lectura:Escritura = 100:1

// Escrituras por segundo:
// 100M / (30 días * 24 horas * 3600 segundos) ≈ 40 URLs/seg

// Lecturas por segundo:
// 40 * 100 = 4,000 redirecciones/seg

// Almacenamiento (5 años):
// Cada registro de URL ≈ 500 bytes
// 100M * 12 meses * 5 años * 500 bytes = 3 TB

Paso 3: Diseño de Alto Nivel (10 minutos)

Dibuja los componentes principales en una pizarra o diagrama. Comienza con clientes, balanceadores de carga, servidores de aplicación, bases de datos y cachés. Dibuja el flujo de datos entre ellos. Esto le da a tu entrevistador una vista panorámica de tu arquitectura antes de que profundices en los detalles.

Paso 4: Inmersión Profunda (15 minutos)

El entrevistador te pedirá que profundices en componentes específicos. Aquí es donde tu conocimiento de bases de datos, caché, colas de mensajes y otra infraestructura entra en juego. Prepárate para discutir:

• Esquema de base de datos y elección de SQL vs NoSQL
• Diseño de API (REST, GraphQL, gRPC)
• Estrategias de particionamiento y replicación de datos
• Capas de caché e invalidación
• Cómo el sistema maneja los fallos

Paso 5: Cierre (5 minutos)

Resume tu diseño, discute las compensaciones que hiciste, identifica posibles cuellos de botella y sugiere mejoras futuras. Esto demuestra madurez y conciencia de que ningún diseño es perfecto.

Cómo Abordar Cualquier Problema de Diseño de Sistemas

Más allá del marco de entrevistas, aquí hay un modelo mental para abordar desafíos de diseño del mundo real:

1. Empieza simple. Comienza con una arquitectura de un solo servidor que maneje todo. Esta es tu línea base.
2. Identifica cuellos de botella. A medida que escales, encuentra el componente que fallará primero — generalmente la base de datos o un punto único de fallo.
3. Aplica patrones conocidos. Usa balanceadores de carga, cachés, colas de mensajes, CDNs y replicación de bases de datos para abordar cuellos de botella específicos.
4. Piensa en modos de fallo. ¿Qué pasa si un servidor se cae? ¿Si la base de datos falla? ¿Si ocurre una partición de red?
5. Considera la complejidad operativa. Un sistema que requiere un doctorado para operar no es un buen sistema. Las arquitecturas más simples son más fáciles de depurar y mantener.
6. Haz las compensaciones explícitas. Cada decisión tiene pros y contras. Documéntalas y prepárate para justificar tus elecciones.