3.0 Introducción a la Parte 3: Sistemas
La arquitectura es el conjunto de decisiones que resulta carísimo revertir. ¿Cómo se divide un sistema en partes? ¿Cómo se comunican entre sí esas partes? ¿Cómo se modelan los datos? Y cómo se comporta el conjunto bajo carga y ante un fallo? La Parte 3 trata precisamente de tomar esas decisiones con intención. En un equipo pequeño, la arquitectura puede vivir en la cabeza de una docena de personas y evolucionar sobre la marcha. En una organización grande (cientos de ingenieros, decenas de equipos, sistemas que sobrevivirán a las carreras de quienes los construyeron) , la arquitectura se convierte en aquello que mantiene a todos coordinados. Cuando es clara, los equipos avanzan con independencia sin chocar el uno contra el otro. Cuando es vaga, cada dependencia entre equipos se convierte en una negociación y cada incidente, en una expedición de arqueología.
Lo que está en juego es mayor en el ámbito empresarial y en la administración pública. Un motor tributario, una plataforma de prestaciones, un historial clínico nacional o el libro mayor de un banco son sistemas de larga duración, fuertemente regulados, compartidos entre departamentos y rendibles ante la ciudadanía. Las decisiones que hoy se toman sobre el acoplamiento, la propiedad de los datos y los atributos de calidad condicionarán lo que sea posible durante una década o más. Regidores y auditores exigen cada vez más una arquitectura documentada y defendible, con evidencia real de que la fiabilidad, la seguridad, la privacidad y la durabilidad fueron diseñadas desde el origen, no añadidas a posteriori. Los fracasos que hacen titulares son fracasos de arquitectura: portales que se derrumban el día del lanzamiento, sistemas de presentación de documentos que se cuelgan en la fecha límite, migraciones que pierden registros o los cuentan en doble.
Esta parte arranca con los fundamentos perdurables, avanza hacia las decisiones estructurales concretas, se adentra luego en las realidades de la distribución, los datos y la escala, y cierra con el problema más difícil al que se enfrentan de hecho la mayoría de las grandes organizaciones: modernizar los sistemas que ya operan. El hilo que lo une todo es una idea sencilla: una buena arquitectura es una sucesión de compromisos conscientes, no una elección de moda.
Capítulos de esta parte
3.1 Fundamentos de arquitectura. Las herramientas duraderas que sobreviven a la moda tecnológica: los atributos de calidad (las «-idades»), los requisitos arquitectónicamente significativos, las funciones de adecuación (pruebas automatizadas que custodian una calidad arquitectónica elegida) y la arquitectura evolutiva; la documentación ligera con el modelo C4 (diagramas de arquitectura anidados en cuatro niveles de zoom) y arc42 (una plantilla de documentación de arquitectura), y el análisis estructurado de alternativas.
3.2 Estilos y patrones arquitectónicos. Un recorrido por las principales formas que puede adoptar un sistema, desde el monolito hasta los microservicios, las arquitecturas basadas en eventos con CQRS (Segregación de Responsabilidades de Comandos y Consultas, que separa los modelos de lectura de los de escritura) y el event sourcing (almacenar el estado como un registro inmutable de eventos en solo lectura aditiva), la malla de servicios (una capa de infraestructura dedicada a la comunicación entre servicios) y las pasarelas, el cómputo serverless, y la arquitectura hexagonal y la arquitectura limpia, con orientaciones sobre cuándo conviene cada una, todo enmarcado por la Ley de Conway (los sistemas tienden a reflejar la estructura comunicativa de la organización que los construye).
3.3 Sistemas distribuidos. Las verdades incómodas que aparecen en el momento en que se cruza una frontera de red (redes poco fiables, fallo parcial, ausencia de reloj compartido) y las defensas estándar: el razonamiento sobre consistencia, la idempotencia (hacer que una operación sea segura de repetir), los reintentos con backoff, los disyuntores (que evitan seguir llamando a una dependencia fallida), las sagas (secuencias de transacciones locales con pasos de compensación en sentido inverso) y la observabilidad distribuida.
3.4 Arquitectura de datos y almacenamiento. Cómo se modelan, almacenan, mantienen consistentes y sirven con rapidez a gran escala los datos: los principales paradigmas de almacenamiento y cuándo usar cada uno, la persistencia políglota (emplear varios almacenes de datos especializados en un mismo sistema), la evolución y migración de esquemas, la caché y las CDN (redes de entrega de contenido), y las transacciones y la concurrencia bajo carga.
3.5 Escalabilidad, rendimiento y resiliencia. Tres cualidades distintas que deben diseñarse desde el origen, no remediarse a posteriori: escalado horizontal y vertical, estado y particionamiento (sharding, que divide los datos entre máquinas según una clave), equilibrado de carga y escalado automático, presupuestos de rendimiento, patrones de resiliencia e ingeniería del caos, y la recuperación ante catástrofes multinota enmarcada por el RTO (objetivo de tiempo de recuperación) y el RPO (objetivo de punto de recuperación).
3.6 Modernización del legado. Los patrones incrementales que de verdad funcionan: la higuera estranguladora (hacer crecer un sistema nuevo alrededor del antiguo hasta que este pueda retirarse) y el reemplazo progresivo tras abstracción (sustituir un componente detrás de una interfaz sobre la rama principal de desarrollo), junto con la evaluación de riesgos del legado, la custodia de mainframes y COBOL (Lenguaje Común de Orientación a Negocios), la migración de datos y la ejecución en paralelo, y la manera de resistir la tentación de la reescritura total que ha producido los fracasos más costosos del sector.
3.7 Mantenimiento de software. La fase dominante del ciclo de vida del software: mantenimiento correctivo, adaptativo, perfeccionador y preventivo, comprensión de programas e ingeniería de reestructuración, y el diseño orientado a la mantenibilidad para que los sistemas de larga vida sigan siendo asequibles de modificar.
3.8 Interoperabilidad y estándares abiertos. Diseñar sistemas para interoperar a través de estándares abiertos en lugar de integraciones a medida: interoperabilidad técnica, sintáctica y semántica, estándares de dominio como FHIR en el ámbito sanitario, y el coste de la dependencia propietaria.
3.9 Ingeniería de sistemas. Ingenierizar sistemas complejos de extremo a extremo, combinando a menudo software, hardware, personas y procesos: ciclo de vida, asignación y trazabilidad de requisitos, interfaces, integración y verificación y validación.
3.10 Sistemas embebidos y en tiempo real. Software para dispositivos bajo restricciones estrictas: comportamiento en tiempo real y determinismo, un RTOS o firmware a nivel de hardware, memoria y energía limitadas, interacción con el hardware y estándares de seguridad crítica.
3.11 Arquitectura en la nube. Diseñar para la nube en lugar de trasladar un centro de datos con la misma lógica: modelos de servicio y serverless, regiones y zonas de disponibilidad como dominios de fallo, el modelo de responsabilidad compartida, los equilibrios entre servicios gestionados y dependencia de un proveedor, el multinube y el híbrido cuando justifican su complejidad, y el diseño económico y bien fundamentado.
3.12 Arquitectura basada en eventos y mensajería. Construir sistemas que se comunican emitiendo y reaccionando a eventos: colas frente a streams duraderos, coreografía frente a orquestación, event sourcing y CQRS donde verdaderamente aportan valor, sagas para transacciones distribuidas, garantías de entrega e idempotencia, y los patrones que mantienen fiables los flujos asíncronos.
3.13 Redes y conectividad. La red que de hecho maneja un ingeniero de aplicaciones: DNS, TCP y la evolución de HTTP, terminación de TLS, equilibrado de carga y proxy inversos, entrega de contenido y capa de borde, descubrimiento de servicios y malla de servicios, y los temporizadores, reintentos y disyuntores que hacen soportable la fiabilidad errática de la red.
3.14 Multitenencia y arquitectura SaaS. Atender a muchos clientes desde una única instancia de software sin que se vean ni se ahoguen entre sí: el espectro entre aislamiento y eficiencia, la partición de datos, las cuotas por inquilino frente a los vecinos ruidosos, el ciclo de vida del inquilino y la atribución de costes.
3.15 Caché y entrega de contenido. Aceptar un poco de caducidad a cambio de grandes ganancias en latencia, carga y coste a lo largo de la jerarquía de caché (cliente, borde y CDN, proxy inverso, aplicación y almacén de datos), tratando la invalidación de caché y la protección contra la avalancha como decisiones de primer orden.
3.16 Pasarelas de API y malla de servicios. Gestionar el tráfico de norte a sur en una pasarela de API (enrutamiento, autenticación, limitación de tasa, composición) y el tráfico de este a oeste a través de una malla de servicios (TLS mutuo, despliegue gradual de tráfico, reintentos, observabilidad), y decidir cuándo una malla justifica su complejidad.
3.17 Búsqueda y recuperación de información. Tratar la búsqueda como un sistema de primer orden, desde el índice invertido y la clasificación por relevancia hasta la comprensión de consultas, la faceting y la recuperación por vectores e híbrida, con una evaluación real de la relevancia en lugar de conjeturas.
Cómo se relacionan estos capítulos
Los capítulos se apoyan unos en otros en el orden que se presenta. El 3.1 aporta el vocabulario (los atributos de calidad y el análisis de alternativas) que cada capítulo posterior emplea; las «-idades» que nombra son exactamente las que los capítulos 3.4 y 3.5 hacen concretas. El 3.2 convierte esos fundamentos en decisiones estructurales, y los estilos más distribuidos que propone (microservicios, basados en eventos, malla de servicios) arrastran los costes que el 3.3 enseña a gestionar. Los capítulos 3.3, 3.4 y 3.5 dependen en gran medida el uno del otro: la distribución impone las decisiones de consistencia y durabilidad de la arquitectura de datos, y juntas, la distribución y los datos determinan qué escalabilidad y resiliencia pueden alcanzarse de verdad. El 3.6 cierra el círculo, porque la mayoría de las grandes organizaciones no construyen sobre una hoja en blanco: evolucionan sistemas de referencia que condicionan cada elección que los capítulos anteriores describen.
La Parte 3 también mira hacia afuera. El capítulo 3.2 se apoya en los principios de diseño y el Domain-Driven Design del capítulo 2.2 para trazar buenos límites de servicio. Las disciplinas operativas que mantienen estos sistemas en marcha viven en la Parte 9: la ingeniería de fiabilidad de sitio (capítulo 9.1) y la observabilidad (capítulo 9.2) son donde la resiliencia arquitectónica se demuestra en producción. Las propiedades de seguridad y privacidad que exigen los reguladores se diseñan aquí, pero se detallan en la Parte 4, y las prácticas de plataforma y entrega de la Parte 8 determinan si una arquitectura puede, de hecho, desplegarse y operarse a la vez por muchos equipos.