01 - Fundamentos del Diseño de Sistemas¶
Tabla de Contenidos¶
Escalabilidad¶
La escalabilidad es la capacidad de un sistema para manejar una cantidad creciente de trabajo añadiendo recursos.
Escalabilidad Vertical (Scale Up)¶
Consiste en aumentar la capacidad de un solo servidor: más CPU, RAM, almacenamiento.
Ventajas: - Simple de implementar (no requiere cambios en la aplicación) - Sin complejidad de coordinación entre nodos - Consistencia de datos garantizada (un solo nodo)
Desventajas: - Límite físico del hardware - Punto único de fallo (SPOF) - Costo exponencial (el hardware enterprise es desproporcionadamente caro) - Downtime durante el upgrade
Ejemplo práctico: Una base de datos PostgreSQL en un servidor con 4 vCPU y 8GB RAM que se migra a 16 vCPU y 64GB RAM.
Escalabilidad Horizontal (Scale Out)¶
Consiste en añadir más máquinas al pool de recursos.
Ventajas: - Escalabilidad teóricamente infinita - Tolerancia a fallos (si un nodo cae, los demás continúan) - Costo lineal con hardware commodity - Sin downtime para escalar
Desventajas: - Complejidad en la consistencia de datos - Necesidad de balanceo de carga - Sesiones distribuidas (stateless vs stateful) - Mayor complejidad operacional
Ejemplo práctico: Una API en Node.js detrás de un load balancer con 3 instancias que se escala a 10 instancias durante Black Friday.
Diagrama Comparativo¶
graph TB
subgraph "Escalabilidad Vertical"
A[Servidor Pequeño<br/>2 CPU, 4GB RAM] -->|Upgrade| B[Servidor Grande<br/>32 CPU, 128GB RAM]
end
subgraph "Escalabilidad Horizontal"
C[Load Balancer] --> D[Servidor 1]
C --> E[Servidor 2]
C --> F[Servidor 3]
C -->|Añadir| G[Servidor N...]
end
Cuándo Usar Cada Una¶
| Criterio | Vertical | Horizontal |
|---|---|---|
| Presupuesto limitado | Inicialmente más barato | Más barato a largo plazo |
| Base de datos relacional | Preferido (consistencia) | Requiere sharding |
| Aplicaciones stateless | Funciona | Ideal |
| Alta disponibilidad | No resuelve SPOF | Naturalmente redundante |
| Complejidad operacional | Baja | Alta |
Disponibilidad¶
La disponibilidad mide el porcentaje de tiempo que un sistema está operativo y accesible.
SLA (Service Level Agreement)¶
Contrato formal entre proveedor y cliente que define los niveles mínimos de servicio. Incluye penalizaciones si no se cumplen.
Ejemplo: AWS EC2 garantiza 99.99% de disponibilidad mensual. Si no lo cumple, otorga créditos al cliente.
SLO (Service Level Objective)¶
Objetivo interno del equipo de ingeniería, generalmente más estricto que el SLA.
Ejemplo: El SLA es 99.9%, pero el equipo apunta a un SLO de 99.95%.
SLI (Service Level Indicator)¶
La métrica real medida que alimenta los SLO.
Ejemplo: Porcentaje de requests HTTP que responden con status 2xx en menos de 300ms.
Tabla de los "Nueves"¶
| Disponibilidad | Downtime/año | Downtime/mes | Downtime/semana |
|---|---|---|---|
| 99% (dos nueves) | 3.65 días | 7.31 horas | 1.68 horas |
| 99.9% (tres nueves) | 8.77 horas | 43.83 min | 10.08 min |
| 99.99% (cuatro nueves) | 52.60 min | 4.38 min | 1.01 min |
| 99.999% (cinco nueves) | 5.26 min | 26.30 seg | 6.05 seg |
Disponibilidad en Serie vs Paralelo¶
En serie (componentes dependientes): La disponibilidad total disminuye.
En paralelo (componentes redundantes): La disponibilidad total aumenta.
graph LR
subgraph "En Serie - 99.7%"
S1[Web Server<br/>99.9%] --> S2[App Server<br/>99.9%] --> S3[DB<br/>99.9%]
end
subgraph "En Paralelo - 99.9999%"
P1[DB Primary<br/>99.9%]
P2[DB Replica<br/>99.9%]
end
Error Budget¶
El error budget es el downtime permitido según el SLO. Si tu SLO es 99.9%, tu error budget mensual es ~43 minutos. Esto permite al equipo tomar decisiones:
- Si queda budget: se pueden hacer deploys más agresivos
- Si se agotó: freeze de deploys, foco en estabilidad
Fiabilidad¶
La fiabilidad es la probabilidad de que un sistema funcione correctamente durante un periodo dado. Un sistema puede estar disponible pero no ser fiable si produce resultados incorrectos.
Conceptos Clave¶
MTBF (Mean Time Between Failures): Tiempo promedio entre fallos. Mayor MTBF = mayor fiabilidad.
MTTR (Mean Time To Recovery): Tiempo promedio para recuperarse de un fallo. Menor MTTR = mejor respuesta operacional.
Estrategias para Mejorar la Fiabilidad¶
- Redundancia: Duplicar componentes críticos (bases de datos, servidores)
- Replicación: Mantener copias de datos en múltiples ubicaciones
- Pruebas de caos (Chaos Engineering): Inyectar fallos deliberadamente para descubrir debilidades (Netflix Chaos Monkey)
- Circuit Breakers: Prevenir cascadas de fallos entre servicios
- Graceful Degradation: El sistema sigue funcionando con funcionalidad reducida ante fallos parciales
- Health Checks: Monitoreo activo para detectar y reemplazar componentes fallidos
graph TD
A[Fallo Detectado] --> B{Circuit Breaker}
B -->|Cerrado| C[Request Normal]
B -->|Abierto| D[Respuesta Fallback]
B -->|Semi-abierto| E[Request de Prueba]
E -->|Éxito| C
E -->|Fallo| D
Latencia vs Rendimiento¶
Dos métricas que frecuentemente se confunden pero miden cosas distintas.
Latencia¶
Tiempo que tarda una operación individual en completarse (medido en ms/s).
Tipos de latencia: - Network latency: Tiempo de ida y vuelta de un paquete (RTT) - Application latency: Tiempo de procesamiento de la lógica de negocio - Database latency: Tiempo de ejecución de queries
Percentiles: No uses solo el promedio. Mide p50, p95, p99.
| Percentil | Significado |
|---|---|
| p50 (mediana) | 50% de requests son más rápidas que este valor |
| p95 | 95% de requests son más rápidas |
| p99 | 99% de requests son más rápidas |
| p99.9 | Peor caso práctico (tail latency) |
Ejemplo: Si p50 = 50ms y p99 = 2000ms, tu usuario promedio tiene buena experiencia pero 1 de cada 100 espera 2 segundos.
Rendimiento (Throughput)¶
Cantidad de operaciones que el sistema procesa por unidad de tiempo (requests/segundo, transacciones/segundo).
La Relación¶
No son inversamente proporcionales de forma simple:
graph LR
A[Baja Carga] -->|Latencia baja<br/>Throughput bajo| B[Zona Óptima]
B -->|Latencia estable<br/>Throughput creciente| C[Capacidad Máxima]
C -->|Latencia crece exponencialmente<br/>Throughput se estanca| D[Saturación]
Números de Latencia que Todo Ingeniero Debe Saber¶
| Operación | Latencia Aproximada |
|---|---|
| Cache L1 | 0.5 ns |
| Cache L2 | 7 ns |
| RAM | 100 ns |
| SSD random read | 150 μs |
| HDD random read | 10 ms |
| Red dentro del mismo datacenter | 0.5 ms |
| Red intercontinental | 150 ms |
| Lectura secuencial 1 MB desde SSD | 1 ms |
| Lectura secuencial 1 MB desde HDD | 20 ms |
| Lectura secuencial 1 MB desde red 1 Gbps | 10 ms |
Recursos Recomendados¶
- Libro: Designing Data-Intensive Applications - Martin Kleppmann (Capítulos 1-2)
- Libro: Site Reliability Engineering - Google (Capítulos 3-4 sobre SLOs)
- Paper: "The Tail at Scale" - Jeff Dean & Luiz André Barroso (Google)
- Video: System Design Primer - GitHub repo de Donne Martin
- Herramienta: uptime.is - Calculadora de SLA/downtime
- Blog: High Scalability - highscalability.com