{"id":26993,"date":"2026-06-18T12:00:00","date_gmt":"2026-06-18T10:00:00","guid":{"rendered":"https:\/\/immune.institute\/?p=26993"},"modified":"2026-06-12T12:11:16","modified_gmt":"2026-06-12T10:11:16","slug":"que-implica-disenar-una-arquitectura-de-software-escalable","status":"publish","type":"post","link":"https:\/\/immune.institute\/en\/blog\/que-implica-disenar-una-arquitectura-de-software-escalable\/","title":{"rendered":"Qu\u00e9 implica dise\u00f1ar una arquitectura de software escalable"},"content":{"rendered":"

El puente que naci\u00f3 peque\u00f1o<\/strong><\/h2>\n\n\n\n

En 1986, los ingenieros espa\u00f1oles comenzaron a dise\u00f1ar el que ser\u00eda el puente m\u00e1s ambicioso de Sevilla: el Puente del Centenario, un viaducto atirantado de 265 metros de vano central que cruzar\u00eda el Guadalquivir para dar servicio a la ronda de circunvalaci\u00f3n SE-30, construida con tres carriles por sentido en todo su recorrido. El Ministerio de Obras P\u00fablicas recibi\u00f3 entonces informes desfavorables de sus propios t\u00e9cnicos sobre la evoluci\u00f3n del tr\u00e1fico prevista: el puente necesitaba tres carriles por sentido para ser coherente con el resto de la v\u00eda. La decisi\u00f3n, sin embargo, fue otra. El Ayuntamiento de Sevilla exigi\u00f3 cuatro carriles totales \u2014dos por sentido\u2014 y la obra ya hab\u00eda comenzado cuando lleg\u00f3 el momento de rectificar. Modificar el proyecto habr\u00eda retrasado la inauguraci\u00f3n prevista para la Expo 92. Se mantuvo el dise\u00f1o original.<\/p>\n\n\n\n

El puente se inaugur\u00f3 el 15 de noviembre de 1991, con un carril reversible como soluci\u00f3n de emergencia para compensar la capacidad insuficiente. En marzo de 1992 \u2014apenas cuatro meses despu\u00e9s\u2014 se elimin\u00f3 la mediana de hormig\u00f3n y los arcenes para habilitar un tercer carril, reduciendo la velocidad m\u00e1xima a 60 km\/h en plena autov\u00eda. Desde entonces, el Centenario es uno de los puntos negros del tr\u00e1fico europeo<\/a>: atasco cr\u00f3nico, radar entre los m\u00e1s activos de Espa\u00f1a y una ampliaci\u00f3n iniciada en 2021 \u2014treinta a\u00f1os tarde\u2014 que a principios de 2026 sigue sin concluir, con un sobrecoste ya superior al 50% del presupuesto inicial.<\/p>\n\n\n\n

El Puente del Centenario no fall\u00f3 por mala ingenier\u00eda: el dise\u00f1o estructural es s\u00f3lido. Fall\u00f3 porque nadie dimension\u00f3 correctamente la carga futura. Se construy\u00f3 para el tr\u00e1fico de 1991 en una ciudad que iba a crecer. El resultado es una infraestructura que desde su primer d\u00eda de uso ya estaba por debajo de las necesidades reales, y cuyo coste de ampliaci\u00f3n posterior ha multiplicado varias veces lo que habr\u00eda costado dise\u00f1arla 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\u00f1ar un sistema que pueda crecer ma\u00f1ana sin tener que rehacerlo entero.<\/em><\/p>\n\n\n\n

Qu\u00e9 significa que una arquitectura escale<\/strong><\/h2>\n\n\n\n

Una arquitectura de software escalable es cuando puede asumir m\u00e1s carga sin obligar a rehacer el sistema entero ni degradar de forma descontrolada la experiencia de uso. Ese crecimiento puede venir por m\u00e1s usuarios concurrentes, m\u00e1s operaciones por segundo, m\u00e1s volumen de datos o una l\u00f3gica de negocio cada vez m\u00e1s exigente. Hay dos formas generales de aumentar capacidad.<\/p>\n\n\n\n

El escalado vertical a\u00f1ade recursos a una instancia concreta \u2014m\u00e1s CPU o memoria\u2014. El escalado horizontal reparte trabajo entre varias instancias o nodos, algo habitual cuando se quiere ganar elasticidad y reducir puntos \u00fanicos de saturaci\u00f3n. <\/p>\n\n\n\n

La diferencia parece sencilla, pero tiene consecuencias t\u00e9cnicas directas: escalar horizontalmente exige tratar bien el estado de la aplicaci\u00f3n, la coordinaci\u00f3n entre componentes y la tolerancia a fallos. Si estos elementos no est\u00e1n resueltos, a\u00f1adir m\u00e1s instancias no garantiza un mejor comportamiento. Es como a\u00f1adir un carril reversible al Centenario: alivia, pero no resuelve.<\/p>\n\n\n\n

Las decisiones que importan de verdad<\/strong><\/h2>\n\n\n\n

La ruta de cada petici\u00f3n y el procesamiento as\u00edncrono<\/strong><\/h3>\n\n\n\n

Una arquitectura preparada para crecer evita cadenas largas de dependencias s\u00edncronas, porque cada salto a\u00f1ade latencia y aumenta la probabilidad de error. Cuando una operaci\u00f3n no necesita respuesta inmediata, usar colas o procesamiento as\u00edncrono descarga la ruta cr\u00edtica y estabiliza el sistema bajo demanda alta. Es el equivalente a un carril de servicio paralelo: el tr\u00e1fico urgente fluye sin bloquearse por el tr\u00e1fico de carga.<\/p>\n\n\n\n

Cuellos de botella y resiliencia<\/strong><\/h3>\n\n\n\n

Muchos sistemas no dejan de escalar por la capa de aplicaci\u00f3n, sino por sus dependencias: la base de datos, la memoria o los servicios externos. Si toda la carga termina concentr\u00e1ndose en un \u00fanico punto, ese componente marca el techo real del sistema \u2014igual que el Centenario marca el techo de la SE-30, aunque el resto de la circunvalaci\u00f3n tenga tres carriles libres. <\/p>\n\n\n\n

La resiliencia tambi\u00e9n forma parte de la escalabilidad. Cuando un servicio empieza a responder m\u00e1s lento, el resto del sistema puede empeorar r\u00e1pidamente si no hay l\u00edmites. Bajo sobrecarga, a veces es mejor rechazar parte del tr\u00e1fico pronto que intentar atenderlo todo y provocar una ca\u00edda general.<\/p>\n\n\n\n

El riesgo de los reintentos mal dise\u00f1ados<\/strong><\/h2>\n\n\n\n

Uno de los errores m\u00e1s comunes en sistemas distribuidos es pensar que reintentar siempre ayuda. Los reintentos autom\u00e1ticos pueden amplificar un problema peque\u00f1o y convertirlo en un fallo en cascada si se lanzan sobre un servicio ya al l\u00edmite: una tasa baja de errores se transforma en mucho m\u00e1s tr\u00e1fico cuando los clientes repiten llamadas sin una pol\u00edtica correcta. La pr\u00e1ctica generalmente aceptada es limitar el n\u00famero de reintentos y diferenciar entre errores recuperables y permanentes. <\/p>\n\n\n\n

La definici\u00f3n de operaciones fallidas es igualmente cr\u00edtica. Si los timeouts son demasiado altos, el sistema mantiene trabajo in\u00fatil y bloquea recursos que podr\u00edan atender otras peticiones v\u00e1lidas. Si son demasiado bajos, operaciones costosas fallar\u00e1n de forma sistem\u00e1tica. El equilibrio depende del tipo de servicio, su latencia normal y c\u00f3mo se propagan esos l\u00edmites entre componentes.<\/p>\n\n\n\n

Visibilidad: no se puede escalar lo que no se mide<\/strong><\/h2>\n\n\n\n

No se puede dise\u00f1ar una arquitectura software escalable sin medir c\u00f3mo se comporta. M\u00e9tricas, logs, trazas distribuidas, alertas y pruebas de carga permiten saber d\u00f3nde aparece la latencia, qu\u00e9 dependencia se convierte en cuello de botella y a partir de qu\u00e9 punto el sistema entra en degradaci\u00f3n. Sin esa informaci\u00f3n, las decisiones arquitect\u00f3nicas se basan en intuiciones y no en comportamiento observado. <\/p>\n\n\n\n

El Centenario tuvo sus se\u00f1ales: los informes t\u00e9cnicos de 1986 ya advert\u00edan de la insuficiencia del dise\u00f1o. Ignorarlas cost\u00f3 treinta a\u00f1os de atascos y m\u00e1s de cien millones de euros en una ampliaci\u00f3n que podr\u00eda haberse evitado. En software, ignorar los indicadores de rendimiento tiene el mismo efecto: se acumula \u201cdeuda t\u00e9cnica<\/a>\u201d, se a\u00f1aden parches y el coste de la soluci\u00f3n definitiva crece exponencialmente con el tiempo.<\/p>\n\n\n\n

Dise\u00f1ar con compromisos reales<\/strong><\/h2>\n\n\n\n

Dise\u00f1ar 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:<\/p>\n\n\n\n

    \n
  • Simplicidad frente a flexibilidad futura: un dise\u00f1o m\u00e1s simple es m\u00e1s f\u00e1cil de operar hoy, pero puede requerir m\u00e1s trabajo para adaptarse ma\u00f1ana.<\/li>\n\n\n\n
  • 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.<\/li>\n\n\n\n
  • Coste operativo frente a independencia de despliegue: m\u00e1s servicios independientes dan m\u00e1s autonom\u00eda a los equipos, pero elevan el coste de automatizaci\u00f3n y gobierno.<\/li>\n\n\n\n
  • Escalado anticipado frente a sobreingenier\u00eda: dise\u00f1ar para diez veces la carga actual puede ser una inversi\u00f3n o un derroche, dependiendo de si ese crecimiento llega.<\/li>\n<\/ul>\n\n\n\n

    El Puente del Centenario ense\u00f1a que el coste de no escalar correctamente desde el dise\u00f1o no se paga en el momento del lanzamiento, sino de forma acumulada y dolorosa durante d\u00e9cadas. En software, esa factura llega en forma de incidencias en producci\u00f3n, deuda t\u00e9cnica creciente, equipos frenados y oportunidades de negocio perdidas. <\/p>\n\n\n\n

    La arquitectura escalable no es un lujo t\u00e9cnico: es la diferencia entre un sistema que crece con el negocio y uno que lo frena.<\/p>","protected":false},"excerpt":{"rendered":"

    Dise\u00f1ar una arquitectura de software escalable implica crear sistemas capaces de crecer sin degradar rendimiento, estabilidad ni mantenibilidad.<\/p>","protected":false},"author":20,"featured_media":26995,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"ai_generated_summary":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-26993","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/posts\/26993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/comments?post=26993"}],"version-history":[{"count":1,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/posts\/26993\/revisions"}],"predecessor-version":[{"id":28331,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/posts\/26993\/revisions\/28331"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/media\/26995"}],"wp:attachment":[{"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/media?parent=26993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/categories?post=26993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/immune.institute\/en\/wp-json\/wp\/v2\/tags?post=26993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}