System Design
Rendimiento y capacidad
Explica cómo estimar carga, volumen, latencia, throughput, almacenamiento y cuellos de botella para diseñar capacidad con evidencia y márgenes explícitos.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo estimar carga, volumen, latencia, throughput, almacenamiento y cuellos de botella para diseñar capacidad con evidencia y márgenes explícitos.
Rendimiento no significa “hacerlo rápido”. Significa comprender qué recurso se consume, qué carga se espera, dónde aparece la espera y qué evidencia demuestra que una optimización es necesaria.
El diseño de capacidad traduce demanda de negocio a carga técnica: solicitudes, concurrencia, almacenamiento, ancho de banda, conexiones y trabajo asíncrono. Después identifica cuellos de botella y define cómo medirlos.
Sin estimaciones, el equipo puede sobrediseñar para millones de usuarios inexistentes o descubrir demasiado tarde que una base, API externa o cola no soporta el pico real.
Las estimaciones no buscan precisión contable; buscan órdenes de magnitud y supuestos explícitos.
usuarios y comportamiento
→ tráfico promedio y pico
→ trabajo por solicitud
→ recursos consumidos
→ límites de cada componente
→ margen y estrategia de escalado
→ prueba con evidenciaTiempo de una operación. Usa percentiles como p50, p95 y p99; el promedio puede ocultar una cola lenta.
Cantidad de trabajo completado por unidad de tiempo: solicitudes, mensajes o transacciones.
Trabajo simultáneo activo. Se relaciona con throughput y tiempo mediante una aproximación de Little:
concurrencia ≈ throughput × latenciaQué tan cerca está un recurso de su límite: CPU, memoria, I/O, conexiones, threads o lag.
Debe analizarse junto con latencia; un sistema puede parecer rápido porque rechaza trabajo.
Supón 10 millones de lecturas al día:
QPS promedio = 10 000 000 / 86 400 ≈ 116
factor de pico = 10
QPS pico ≈ 1 160El factor de pico depende del producto. Un evento comercial puede concentrar tráfico en minutos, no distribuirlo uniformemente.
registros por día × tamaño medio × retenciónPara 500 000 registros diarios de 2 KB durante un año:
≈ 365 GB de datos baseLuego añade:
El tamaño lógico de un JSON no equivale al coste físico real.
requests/s × payload medioDistingue entrada y salida. Imágenes, descargas o respuestas repetidas pueden dominar el coste aunque el backend procese pocas operaciones.
Una base puede soportar menos conexiones activas eficientes que solicitudes concurrentes.
30 instancias × pool 20 = 600 conexiones potencialesEscalar horizontalmente sin limitar pools puede empeorar el sistema. Un pool debe reflejar trabajo real y capacidad del downstream.
Se consume en serialización, compresión, cifrado, lógica y consultas. Más CPU no ayuda si la espera está en red o disco.
Cachés, heaps, buffers y payloads grandes pueden provocar presión, pausas o OOM.
Bases y almacenamiento dependen de latencia, IOPS y throughput. Consultas con acceso aleatorio pueden saturar antes que el tamaño total.
Llamadas entre regiones o servicios añaden latencia y variabilidad.
Si el SLO del endpoint es p95 menor a 500 ms:
Gateway 30 ms
API 60 ms
Database 120 ms
Payment 200 ms
Margen 90 msLas llamadas secuenciales suman latencia. Las paralelas reducen tiempo total, pero elevan concurrencia y complejidad.
No optimices cada componente por igual. Identifica operaciones que dominan el tiempo de respuesta o el coste.
request
→ auth 20 ms
→ DB 40 ms
→ proveedor externo 700 msOptimizar 5 ms en la base no resuelve el proveedor de 700 ms.
La caché intercambia consistencia, memoria y complejidad por menor latencia o carga.
Decide:
No cachees por intuición; mide hit rate y coste evitado.
Una cola desacopla llegada y procesamiento. La capacidad no se mide solo en mensajes por segundo:
lag time = cuánto tarda el mensaje más antiguo relevanteSi la entrada sostenida supera el consumo, la cola solo retrasa el agotamiento. Se necesita escalar, limitar o degradar.
Simple y útil hasta cierto punto. Puede aumentar el dominio de fallo.
Añade instancias, pero exige estado externo, balanceo y coordinación.
Distribuye datos o trabajo. Introduce routing, hot keys y consultas cruzadas.
La decisión debe responder al cuello medido.
Supuestos:
Diseño inicial:
Criterio de revisión:
Valida carga esperada.
Busca el punto de ruptura.
Evalúa aumentos bruscos.
Detecta fugas y degradación prolongada.
Estima margen y crecimiento.
Usa datos, cardinalidades y distribución realistas. Un test con una tabla pequeña y caché caliente puede engañar.
Cuando la utilización se acerca al 100 %, la espera crece de forma no lineal. Operar con margen es necesario para absorber variación y fallos.
Un tenant o producto concentra tráfico y rompe un particionamiento aparentemente uniforme.
Después de despliegue o expiración masiva, la base recibe una oleada.
Timeouts generan retries que multiplican la carga.
Una respuesta que antes pesaba 5 KB ahora pesa 500 KB por relaciones añadidas.
Filtros, exportaciones o consultas permiten consumir recursos arbitrarios.
Muchos usuarios actúan al mismo tiempo por una campaña o cierre diario.
Cuando no existe problema medido, el volumen cabe con margen o la complejidad adicional supera el beneficio. El diseño simple con puntos de evolución suele ser mejor que una solución distribuida prematura.
Disponibilidad, resiliencia y recuperación diseña el comportamiento cuando componentes se vuelven lentos, fallan o pierden datos.