Scaling
Capacidad que cambia y límites que permanecen
Scaling responde qué capacidad necesita crecer o reducirse frente a cambios de demanda, cómo puede hacerlo y qué recursos, estados o dependencias limitan ese cambio. Antes de elegir réplicas, preguntar qué trabajo aumenta, qué se satura, cuál es la unidad ampliable y qué dependencia será el siguiente límite.
En el Atlas es un eje de architecture-decision-axes, no un profile, Quality Attribute, autoscaler, load balancer ni optimización aislada. architecture-profile agrupa decisiones sobre varios ejes; ninguno garantiza Scaling por su nombre. El foco es capacidad técnica del sistema, no crecimiento de equipos.
Scaling, Scalability, Elasticity y Performance
La convención editorial distingue Scaling, decisiones y mecanismos para cambiar capacidad, de scalability, capacidad del sistema para sostener crecimiento bajo condiciones declaradas. La literatura usa fronteras terminológicas variables; esta distinción organiza el Atlas sin pretender una definición universal.
Elasticity añade adaptación de capacidad a demanda cambiante durante el tiempo, frecuentemente automática. Herbst, Kounev y Reussner distinguen adaptación temporal de habilidad para aprovechar recursos adicionales. Scaling manual sigue siendo Scaling; autoscaling es un mecanismo posible, no la definición del eje. Elasticity in Cloud Computing, secciones 2.1–2.4.
Performance describe latencia, throughput y consumo en ciertas condiciones. Una aplicación rápida bajo poca carga puede deteriorarse al crecer; una arquitectura ampliable puede conservar una latencia absoluta inaceptable. Optimizar un algoritmo puede liberar margen sin añadir recursos, pero no prueba crecimiento sostenido.
Load, Capacity y forma del trabajo
Load es trabajo presentado; capacity es cantidad o tasa sostenible bajo condiciones acordadas de servicio, recursos y mezcla de operaciones. Importan llegada, concurrencia, costo por operación, payload, localidad, acceso a estado y burstiness.
Mil lecturas pequeñas no equivalen a mil búsquedas intensivas ni a mil uploads grandes. Google SRE advierte que modelar capacidad solamente mediante queries por segundo puede fallar cuando cambia el costo de las consultas. Handling Overload, The Pitfalls of Queries per Second.
El volumen de datos también crece aunque el tráfico permanezca estable: índices, storage, backups y mantenimiento pueden superar límites. Más usuarios o regiones pueden exigir localidad y nuevos recorridos de red. La tasa de requests no representa todas esas demandas.
Bottleneck y capacidad de extremo a extremo
Un bottleneck es el recurso o recorrido que limita el trabajo útil considerado. Puede estar en CPU, memoria, IOPS, red, locks, conexiones, consumidores, cache, un coordinador o una cuota externa. Su ubicación depende del workload; quitarlo puede revelar otro.
En Commerce, Orders llama a Payments, que persiste resultados y utiliza un proveedor externo. Duplicar Orders no aumenta autorizaciones completadas si la cuota del proveedor permanece agotada. dependency-structure ayuda a identificar capacidades necesarias que no controlamos.
Latencia creciente en Orders es un síntoma, no prueba de CPU insuficiente. Más réplicas pueden abrir conexiones y elevar contención en la base compartida. Escalar un tier no equivale a escalar el sistema: hay que seguir el recorrido del resultado útil y sus límites.
Vertical y horizontal, sin escalera de madurez
Vertical scaling, up/down, cambia recursos de una unidad de ejecución: CPU, memoria o capacidad de I/O. Puede mantener topología simple y reducir coordinación, incluso para trabajo stateful. Tiene techos de hardware, proveedor y licencias, curvas de costo y posibles reinicios o migraciones; una unidad mayor también puede concentrar más impacto de fallo.
Horizontal scaling, out/in, cambia el número de unidades o participantes. Puede distribuir trabajo y añadir capacidad incremental, con oportunidades de redundancia. Exige routing, estado, coordinación, consistencia y operación de participantes adicionales. Iniciar N copias sin distribuir trabajo útil no consigue ese resultado.
Ninguna opción es una etapa superior. Pueden combinarse; el estudio Autopilot ilustra ajuste de cantidad de tareas y recursos por tarea, con compromisos de utilización y riesgo de degradación. Autopilot: Workload Autoscaling at Google Scale. La elección necesita architectural-drivers, no preferencias por una topología moderna.
Unidad y granularidad de Scaling
La unidad ampliable puede ser aplicación, servicio, worker pool, partición, réplica de datos o grupo de consumidores. Hay que declararla junto al recurso que aporta. decomposition divide responsabilidades; deployment define unidades instalables; Scaling pregunta qué capacidad cambia. granularity permite comparar esas unidades: sus granularidades pueden coincidir o diferir.
Una aplicación común puede aumentar un pool interno sin instalar otro artifact, hasta los límites de su host. Una capacidad puede usar API y workers desplegados separadamente. Contar módulos, deployments o procesos no identifica automáticamente la unidad de Scaling.
execution-model condiciona el cambio: requests requieren concurrencia útil; workers, procesamiento de pendientes; batch, distribución del workset; streams, asignación de particiones y progreso. Más consumidores no ayudan si una única partición serializada sigue limitando el trabajo.
Stateless facilita opciones; stateful también puede crecer
Stateless execution permite que una instancia adecuada atienda trabajo sin depender del estado de otra instancia particular. El sistema conserva estado en datos, caches, servicios o mensajes. Diez APIs stateless contra una base común pueden trasladar allí el cuello de botella.
Stateful workloads pueden crecer mediante partición, replicación y asignación de responsabilidades de ejecución. Requieren conservar estado, trasladarlo, recuperar fallos y coordinar cambios; stateful no significa imposible de escalar.
data-ownership examina autoridad semántica. Que un nodo sirva una partición es ownership operacional; no lo autoriza a redefinir reglas de Orders. Deben aclararse escritores permitidos, transferencia de responsabilidad y sincronización sin confundir ubicación con autoridad.
Partitioning, keys y hot partitions
Partitioning divide trabajo o estado en subconjuntos suficientemente independientes para distribuir procesamiento. Decomposition puede separar Orders de Payments; particionar Orders por customerId reparte instancias de una responsabilidad. Un shard no equivale a una frontera de servicio ni a una partición de red causada por fallo.
Las claves pueden usar tenant, cliente, pedido, región, hash o rango temporal. Afectan distribución, localidad, consultas, movimiento de datos y aislamiento. Si 80% del trabajo pertenece al mismo país, una división uniforme por country deja una partición caliente. Igual cantidad de registros tampoco demuestra igual costo de procesamiento.
Una hot partition concentra carga desproporcionada. Añadir nodos sin cambiar su asignación o posibilidad de dividirla puede dejar capacidad ociosa. Cambiar key, dividir trabajo, aislar una carga, cachear lecturas o regular admisión son alternativas condicionadas por semántica; no recetas universales.
Bigtable utiliza rangos para conservar localidad; Dynamo examina distribución mediante hashing y ajustes de asignación. Son diseños distintos que muestran por qué distribución y rebalancing requieren decisiones, no una definición basada en un producto. Bigtable, secciones 2 y 5, Dynamo, sección 4.2.
Rebalancing consume red e I/O y puede interrumpir o ralentizar trabajo mientras cambia asignación. Muchas particiones no garantizan throughput equilibrado; el acceso a una clave muy popular puede seguir concentrado aunque el conjunto esté bien repartido.
Replication y lecturas frente a escrituras
Replication mantiene copias o participantes que reproducen estado; Partitioning reparte subconjuntos. Pueden combinarse, pero responden preguntas diferentes. Las notas de Kleppmann explican replicación como conservación de copias y muestran que gestionar cambios necesita protocolos explícitos. Distributed Systems, capítulo 5.
Caches, read replicas o proyecciones pueden repartir lecturas aceptando obligaciones de frescura y actualización. Escrituras pueden seguir limitadas por un writer, locks, coordinación o almacenamiento. Añadir copias no multiplica automáticamente escrituras; puede aumentar tráfico de sincronización.
Replicación puede aportar localidad y redundancia, con lag, failover, consistencia y costo. Tampoco garantiza disponibilidad: participantes dentro del mismo dominio de fallo pueden perderse juntos. isolation y blast-radius permiten examinar esa exposición sin confundir capacidad con contención.
Coordination, Communication y Tenancy
coordination puede exigir locks, acuerdos, orden global o asignación exclusiva de particiones. Serializar una operación crítica limita paralelismo; nuevos participantes también pueden aumentar competencia y sincronización. Localizar invariantes o trabajo reduce ciertas obligaciones cuando la semántica lo permite. Corrección prevalece sobre throughput.
communication cambia al pasar de un endpoint a varios: routing, distribución y afinidad deben sostener los contratos. Fan-out, serialización, conexiones y metadata consumen capacidad; más paralelismo no produce crecimiento indefinido.
Load balancing distribuye trabajo entre capacidad disponible; no crea por sí solo capacidad total adicional, aunque pueda aprovechar capacidad antes ociosa. Capacity añadida sin distribución efectiva también puede quedar inutilizada.
tenancy añade cargas desiguales y cuotas por contexto. isolation puede reservar pools o recursos para crecimiento independiente, a costa de utilización. Réplicas separadas pueden compartir una base o cuota; tenant sharding no define Tenancy ni elimina todos los noisy neighbors.
Colas y Load & Flow: sostener límites
Una cola absorbe bursts y separa llegada de procesamiento temporalmente. Si llegada excede sostenidamente la tasa de salida, el backlog crece; la cola no crea capacidad. queue-management estudia pendientes, límites y espera.
backpressure regula flujo respecto de capacidad downstream. admission-control decide qué aceptar o diferir; load-shedding descarta trabajo para preservar prioridades; rate-limiting aplica límites de demanda según política. flow-control organiza regulación del intercambio. Son relaciones complementarias, no sinónimos de Scaling.
Para una carga temporal o de poco valor, regular demanda puede ser preferible a ampliar recursos. Más consumidores ayudan solo mientras su trabajo tenga margen y no sobrecarguen otra dependencia. El objetivo sigue siendo resultado útil bajo condiciones explícitas.
Señales, demora y reducción de capacidad
CPU, memoria, concurrencia, profundidad de cola, latencia, throughput, backlog de negocio o lag de partición son posibles señales. Una métrica creciente no indica automáticamente qué ampliar. CPU baja puede coexistir con espera por locks o cuota externa; hace falta relacionar señal, cuello de botella y respuesta deseada.
Capacidad reactiva responde después del cambio; una campaña conocida puede justificar preparar recursos antes. Ninguna estrategia elimina incertidumbre ni garantiza demanda prevista. Autoscaling automatiza una política y no soluciona por sí solo overload.
Solicitar recursos no equivale a poder usarlos: provisioning, startup, warm-up y reasignación tardan. Herbst y colaboradores destacan velocidad y precisión de adaptación, además de recursos asignados. Elasticity in Cloud Computing, sección 2.3.
Scale-in debe preservar trabajo en vuelo, sesiones, particiones y conexiones. Drenar, transferir o recuperar progreso requiere contratos; no es simplemente invertir scale-out. Google SRE explica retirada gradual de backends manteniendo solicitudes activas. Load Balancing in the Datacenter, Lame Duck State.
También puede haber oscilación: ampliar reduce una señal, retirar eleva esa señal y se repite el ciclo. Histéresis, cooldown y señales mejor elegidas pueden ayudar, considerando demora y capacidad útil. No sustituyen comprobar comportamiento del mecanismo.
Overload, costo y operación
En retry-storms, fallos y espera generan más intentos y más carga. thundering-herd puede concentrar trabajo al recuperar capacidad. Añadir upstream puede agravar un límite downstream y propagar cascading-failures. Google SRE trata capacidad y protección frente a cascadas como preocupaciones complementarias. Addressing Cascading Failures.
cost-efficiency considera recursos, redundancia, transferencia y operación por servicio útil. Capacidad extra ofrece margen y cuesta; capacidad insuficiente puede abaratar infraestructura y perjudicar resultados. Autoscaling reduce ciertas reservas ociosas y agrega complejidad, sin óptimo universal.
sustainability relaciona utilización y trabajo innecesario con recursos consumidos. Reducir huella no permite incumplir confiabilidad o performance requeridas. operability necesita explicar cambios de capacidad, particiones calientes, instancias saludables, backlog y oscilación. Un mecanismo incomprensible también tiene costo arquitectónico.
Los techos deben registrarse: cuota externa, writer único, particiones, ancho de banda, licencias y capacidad operacional disponible. Capacidad interna creciente no elimina restricciones contractuales ajenas.
Commerce: comparar crecimiento concreto
Supongamos Orders ×4 en tráfico, autorizaciones Payments ×4, escrituras Inventory ×2 y actualizaciones Shipping ×1,5. Son aumentos de trabajo ilustrativos, no tamaños recomendados. Medir costo, recursos saturados y dependencias antes de decidir cantidad de instancias.
En modular-monolith, replicar la aplicación completa conserva simplicidad y puede duplicar capacidad de módulos poco demandados. Pools internos permiten variar concurrencia de algunas actividades dentro del presupuesto común; no garantizan Scaling independiente ilimitado.
En microservices, Orders ×8, Payments ×3 e Inventory ×4 ilustran granularidad potencial. Base, broker o cuota del proveedor pueden seguir limitando el conjunto. monolith también admite crecimiento horizontal; service-based-architecture puede ampliarse por servicios gruesos; service-oriented-architecture requiere examinar capacidad de proveedores e integración.
Tenant A genera 70% de carga, B 20% y C 10%. Un shard por tenant no balancea esa demanda. Revisar si A necesita otra división o capacidad delimitada y qué continúa compartido. Más particiones no solucionan automáticamente un pago externo serializado ni reservas sobre el mismo stock.
Revisar la decisión con evidencia
serverless-architecture ilustra delegación de elasticidad y capacidad a una plataforma. Más invocaciones pueden multiplicar conexiones y saturar una base compartida aunque compute crezca correctamente. Cuotas, concurrencia, particiones y límites downstream siguen condicionando la respuesta end-to-end; autoscaling gestionado no garantiza crecimiento ilimitado.
Declarar trabajo creciente, unidad ampliable, recurso añadido, estado conservado, distribución, límites downstream y tiempo hasta capacidad útil. Comparar también reducción y fallo, no solo un gráfico ascendente.
Las pruebas deben representar mezcla, bursts, estado y dependencias del escenario. Medir latencia y resultados útiles después del cambio; backlog menor o más procesos no bastan. Scaling hace explícita una respuesta arquitectónica que el sistema tendrá incluso si nadie la decidió deliberadamente.
estimation aproxima demanda, concurrencia y volumen para contrastar si esa respuesta es plausible antes de contar con toda la implementación. Sus supuestos, headroom y escenarios de fallo requieren justificación; no existe un porcentaje universal de utilización que convierta la estimación en capacidad demostrada.