Software Architect · Módulo 14
Scalability es la capacidad del sistema de crecer por el eje que importa — sin un aumento desproporcionado de complejidad y costo.
Vertical scaling · horizontal scaling · partitioning · capacity
Se escala una carga concreta: usuarios, writes, reads, volumen de datos, equipos o regiones.
El crecimiento tiene distintas formas
Un restaurante puede crecer agregando mesas, sumando delivery, abriendo cocinas en distintos barrios o acelerando el servicio. Cada opción es una arquitectura distinta.
El vertical scaling agrega recursos a un solo nodo. El horizontal scaling agrega nodos. Las read replicas ayudan a la lectura, no a la escritura. El sharding ayuda con el volumen y la escritura — pero complica las queries, las transacciones y la operación.
El arquitecto tiene que nombrar el axis of scale. Un sistema que escala bien en lecturas puede ser pésimo escalando escrituras. Un servicio que aguanta la carga puede no escalar organizacionalmente si todos los cambios pasan por un único equipo.
Capacity planning le gana al heroísmo
Es más fácil saber de antemano la capacidad del salón que abrir las puertas y rezar para que las paredes se estiren.
El capacity planning responde: cuánta carga aguantamos hoy, qué crecimiento esperamos, dónde está el techo, cuál es el lead time para expandir, qué alarms van a saltar cuando nos acerquemos al límite.
Sin eso, el equipo se entera de los límites por los usuarios. Eso siempre sale más caro.
La scalability tiene que crecer desde el perfil real de carga — no desde el miedo abstracto al futuro.
Ejemplo: un producto read-heavy
En una biblioteca, miles de personas leen los libros, pero un equipo chico edita el catálogo.
Un servicio de documentación tiene muchas lecturas y pocas escrituras. La arquitectura se apoya en un CDN, static generation, edge caching y un search index read-optimised. La source of truth queda simple.
Es un buen trade-off: las lecturas escalan barato y la escritura sigue siendo manejable.
Antiejemplo: sharding antes del primer cliente
Construir un nudo vial de ocho carriles para llegar a un garaje con un solo auto es caro y poco práctico.
El equipo diseña desde el día uno una sharded database, un routing layer y distributed transactions — mientras el producto todavía está buscando market fit. El desarrollo se frena, las migraciones se complican y la carga real sigue siendo desconocida.
La scalability tiene que dejar abierto un camino de crecimiento. No tiene que implementar hoy cada nivel futuro.
- ¿Por qué eje tiene que crecer primero el sistema? - ¿Dónde está hoy el capacity limit? - ¿Qué señal nos avisa que toca cambiar la arquitectura? - ¿Se puede postergar la complejidad sin perder el camino de migración?