El puente que nació pequeño
En 1986, los ingenieros españoles comenzaron a diseñar el que sería el puente más ambicioso de Sevilla: el Puente del Centenario, un viaducto atirantado de 265 metros de vano central que cruzaría el Guadalquivir para dar servicio a la ronda de circunvalación SE-30, construida con tres carriles por sentido en todo su recorrido. El Ministerio de Obras Públicas recibió entonces informes desfavorables de sus propios técnicos sobre la evolución del tráfico prevista: el puente necesitaba tres carriles por sentido para ser coherente con el resto de la vía. La decisión, sin embargo, fue otra. El Ayuntamiento de Sevilla exigió cuatro carriles totales —dos por sentido— y la obra ya había comenzado cuando llegó el momento de rectificar. Modificar el proyecto habría retrasado la inauguración prevista para la Expo 92. Se mantuvo el diseño original.
El puente se inauguró el 15 de noviembre de 1991, con un carril reversible como solución de emergencia para compensar la capacidad insuficiente. En marzo de 1992 —apenas cuatro meses después— se eliminó la mediana de hormigón y los arcenes para habilitar un tercer carril, reduciendo la velocidad máxima a 60 km/h en plena autovía. Desde entonces, el Centenario es uno de los puntos negros del tráfico europeo: atasco crónico, radar entre los más activos de España y una ampliación iniciada en 2021 —treinta años tarde— que a principios de 2026 sigue sin concluir, con un sobrecoste ya superior al 50% del presupuesto inicial.
El Puente del Centenario no falló por mala ingeniería: el diseño estructural es sólido. Falló porque nadie dimensionó correctamente la carga futura. Se construyó para el tráfico de 1991 en una ciudad que iba a crecer. El resultado es una infraestructura que desde su primer día de uso ya estaba por debajo de las necesidades reales, y cuyo coste de ampliación posterior ha multiplicado varias veces lo que habría costado diseñarla bien desde el principio. Este es, exactamente, el problema de la escalabilidad en software: no se trata de construir algo que funcione hoy, sino de diseñar un sistema que pueda crecer mañana sin tener que rehacerlo entero.
Qué significa que una arquitectura escale
Una arquitectura de software escalable es cuando puede asumir más carga sin obligar a rehacer el sistema entero ni degradar de forma descontrolada la experiencia de uso. Ese crecimiento puede venir por más usuarios concurrentes, más operaciones por segundo, más volumen de datos o una lógica de negocio cada vez más exigente. Hay dos formas generales de aumentar capacidad.
El escalado vertical añade recursos a una instancia concreta —más CPU o memoria—. El escalado horizontal reparte trabajo entre varias instancias o nodos, algo habitual cuando se quiere ganar elasticidad y reducir puntos únicos de saturación.
La diferencia parece sencilla, pero tiene consecuencias técnicas directas: escalar horizontalmente exige tratar bien el estado de la aplicación, la coordinación entre componentes y la tolerancia a fallos. Si estos elementos no están resueltos, añadir más instancias no garantiza un mejor comportamiento. Es como añadir un carril reversible al Centenario: alivia, pero no resuelve.
Las decisiones que importan de verdad
La ruta de cada petición y el procesamiento asíncrono
Una arquitectura preparada para crecer evita cadenas largas de dependencias síncronas, porque cada salto añade latencia y aumenta la probabilidad de error. Cuando una operación no necesita respuesta inmediata, usar colas o procesamiento asíncrono descarga la ruta crítica y estabiliza el sistema bajo demanda alta. Es el equivalente a un carril de servicio paralelo: el tráfico urgente fluye sin bloquearse por el tráfico de carga.
Cuellos de botella y resiliencia
Muchos sistemas no dejan de escalar por la capa de aplicación, sino por sus dependencias: la base de datos, la memoria o los servicios externos. Si toda la carga termina concentrándose en un único punto, ese componente marca el techo real del sistema —igual que el Centenario marca el techo de la SE-30, aunque el resto de la circunvalación tenga tres carriles libres.
La resiliencia también forma parte de la escalabilidad. Cuando un servicio empieza a responder más lento, el resto del sistema puede empeorar rápidamente si no hay límites. Bajo sobrecarga, a veces es mejor rechazar parte del tráfico pronto que intentar atenderlo todo y provocar una caída general.
El riesgo de los reintentos mal diseñados
Uno de los errores más comunes en sistemas distribuidos es pensar que reintentar siempre ayuda. Los reintentos automáticos pueden amplificar un problema pequeño y convertirlo en un fallo en cascada si se lanzan sobre un servicio ya al límite: una tasa baja de errores se transforma en mucho más tráfico cuando los clientes repiten llamadas sin una política correcta. La práctica generalmente aceptada es limitar el número de reintentos y diferenciar entre errores recuperables y permanentes.
La definición de operaciones fallidas es igualmente crítica. Si los timeouts son demasiado altos, el sistema mantiene trabajo inútil y bloquea recursos que podrían atender otras peticiones válidas. Si son demasiado bajos, operaciones costosas fallarán de forma sistemática. El equilibrio depende del tipo de servicio, su latencia normal y cómo se propagan esos límites entre componentes.
Visibilidad: no se puede escalar lo que no se mide
No se puede diseñar una arquitectura software escalable sin medir cómo se comporta. Métricas, logs, trazas distribuidas, alertas y pruebas de carga permiten saber dónde aparece la latencia, qué dependencia se convierte en cuello de botella y a partir de qué punto el sistema entra en degradación. Sin esa información, las decisiones arquitectónicas se basan en intuiciones y no en comportamiento observado.
El Centenario tuvo sus señales: los informes técnicos de 1986 ya advertían de la insuficiencia del diseño. Ignorarlas costó treinta años de atascos y más de cien millones de euros en una ampliación que podría haberse evitado. En software, ignorar los indicadores de rendimiento tiene el mismo efecto: se acumula “deuda técnica”, se añaden parches y el coste de la solución definitiva crece exponencialmente con el tiempo.
Diseñar con compromisos reales
Diseñar arquitectura de software exige decidir con restricciones reales. No se trata solo de conocer patrones, sino de entender compromisos entre variables que a menudo se contradicen:
- Simplicidad frente a flexibilidad futura: un diseño más simple es más fácil de operar hoy, pero puede requerir más trabajo para adaptarse mañana.
- Consistencia frente a disponibilidad: un sistema que garantiza que todos los nodos ven el mismo dato en todo momento sacrifica disponibilidad cuando hay fallos de red.
- Coste operativo frente a independencia de despliegue: más servicios independientes dan más autonomía a los equipos, pero elevan el coste de automatización y gobierno.
- Escalado anticipado frente a sobreingeniería: diseñar para diez veces la carga actual puede ser una inversión o un derroche, dependiendo de si ese crecimiento llega.
El Puente del Centenario enseña que el coste de no escalar correctamente desde el diseño no se paga en el momento del lanzamiento, sino de forma acumulada y dolorosa durante décadas. En software, esa factura llega en forma de incidencias en producción, deuda técnica creciente, equipos frenados y oportunidades de negocio perdidas.
La arquitectura escalable no es un lujo técnico: es la diferencia entre un sistema que crece con el negocio y uno que lo frena.
