Arquitectura de software

Es el conjunto de estructuras y decisiones que orientan cómo se organiza un sistema y cómo puede evolucionar. Incluye responsabilidades y límites de sus componentes, interfaces, flujo y propiedad de los datos, dependencias y aspectos operativos relevantes.

No es solo un diagrama, un framework o una lista de tecnologías. Una arquitectura útil explica cómo las decisiones responden a los requisitos del sistema y qué consecuencias tienen para quienes lo desarrollan y operan.

Parte de los requisitos, los límites del dominio, la experiencia del equipo y las necesidades concretas de despliegue y escalado. Un monolito suele simplificar las llamadas internas, las transacciones y la operación inicial. Un monolito modular mantiene límites explícitos dentro de un mismo despliegue. Los microservicios pueden permitir despliegue y escalado independientes, pero agregan comunicación de red, fallos distribuidos, coordinación de datos, observabilidad y trabajo operativo.

No elijas microservicios solo por popularidad. Si todavía no hay una necesidad clara de independencia entre equipos, componentes o ciclos de despliegue, empieza con una estructura modular y revisa la decisión cuando aparezca evidencia. La guía de estilos de arquitectura de Microsoft describe beneficios y costos de varios estilos.

Convierte frases vagas en escenarios que se puedan observar y medir. Por ejemplo: ante una carga definida, el servicio debe mantener un percentil de latencia acordado; después de una falla, debe recuperarse dentro de un tiempo objetivo y limitar la pérdida de datos.

Prioriza esos escenarios con las personas interesadas y registra sus límites. Las decisiones suelen implicar compromisos entre seguridad, confiabilidad, rendimiento, costo, operación y sostenibilidad; hay que evaluarlos en el contexto real del producto. El marco Well-Architected de AWS presenta estos aspectos como pilares para revisar una arquitectura.

Agrupa responsabilidades que cambian juntas y pertenecen a una misma capacidad del negocio. Busca alta cohesión dentro del límite, pocas dependencias innecesarias entre límites y contratos explícitos. En sistemas de dominio complejo, un contexto delimitado ayuda a establecer dónde aplica un modelo y un vocabulario particular.

Evita separar servicios únicamente por capas técnicas, como crear un servicio por cada tabla o capa de acceso a datos. Revisa los límites conforme cambien el dominio, los requisitos y la forma en que los equipos trabajan. Microsoft explica este proceso de análisis de dominio y contextos delimitados.

Úsala cuando varios consumidores necesitan reaccionar a cambios, cuando las tareas pueden procesarse de forma asíncrona o cuando conviene desacoplar el ritmo y la disponibilidad de productores y consumidores. En una arquitectura síncrona, una solicitud normalmente espera la respuesta inmediata de su dependencia; con eventos, quien publica no necesita conocer a cada consumidor.

El desacoplamiento tiene costos: un consumidor puede recibir duplicados, observar eventos fuera del orden esperado o actualizarse después que el productor. Diseña para idempotencia, evolución de contratos, trazabilidad y manejo de fallos. La guía de arquitectura orientada a eventos de Microsoft describe esos usos y desafíos.

CQRS separa los modelos o caminos usados para modificar datos de los usados para consultarlos. Esa separación puede facilitar reglas de escritura complejas y optimizar consultas con necesidades distintas; primero puede aplicarse manteniendo una sola base de datos.

Separar también las bases de datos aumenta el trabajo de sincronización y puede hacer que las lecturas estén temporalmente atrasadas. No es necesario para una interfaz CRUD simple ni significa automáticamente usar Event Sourcing. Aplícalo cuando haya una necesidad concreta y medible, como perfiles de carga de lectura y escritura muy distintos. La documentación de Microsoft sobre CQRS detalla sus variantes y compromisos.

Define tiempos límite para las llamadas de red. Reintenta solo fallos transitorios, con una cantidad finita de intentos y esperas adecuadas, por ejemplo con retroceso exponencial y variación aleatoria. Comprueba que la operación se pueda repetir sin duplicar efectos antes de reintentarla.

Un interruptor de circuito detiene temporalmente las llamadas a una dependencia que falla de forma persistente y permite probar su recuperación después. Úsalo cuando ayude a contener fallos en cascada; no sustituye los tiempos límite, el manejo de errores ni una estrategia de recuperación. Consulta las guías de Microsoft sobre fallos transitorios e interruptor de circuito.

Un registro breve debe documentar el contexto y el problema, la decisión adoptada y sus consecuencias. Puede anotar alternativas consideradas, fecha y estado para que el equipo entienda qué se aceptó y por qué.

Registra decisiones que condicionen estructura, dependencias, interfaces o atributos de calidad; no hace falta crear uno para cada detalle de implementación. Si nueva evidencia cambia la decisión, escribe un registro nuevo que reemplace al anterior y conserve el historial. La guía de AWS sobre registros de decisiones arquitectónicas explica el propósito y el ciclo de vida de los ADR.

Identifica primero las suposiciones de mayor riesgo y crea una prueba vertical o un prototipo que las ejercite. Mide los escenarios de calidad prioritarios bajo cargas realistas; ensaya también fallos, recuperación, seguridad, despliegue y observabilidad.

Compara los resultados con los objetivos acordados y cambia el diseño si no los cumple. Los diagramas y argumentos ayudan a comunicar, pero no sustituyen la evidencia obtenida al probar los riesgos principales. El marco Well-Architected de AWS recomienda medir el impacto de los compromisos de arquitectura.

Primero aclara quién usa el sistema, sus funciones principales, la escala esperada, las restricciones y los objetivos de calidad. Después estima cargas y tamaños cuando ayude a tomar decisiones, dibuja los componentes y sus flujos de datos, y explica los principales compromisos.

Profundiza en los riesgos más relevantes, como consistencia, fallos, seguridad, latencia y operación. Resume las decisiones y lo que validarías con un prototipo. No empieces eligiendo una nube o un framework antes de entender el problema.

CAP describe un límite para sistemas distribuidos cuando ocurre una partición de red: el sistema debe decidir si responde manteniendo consistencia fuerte o si sigue respondiendo con disponibilidad, aceptando que algunas respuestas puedan estar desactualizadas o en conflicto.

No significa que un sistema elija permanentemente dos propiedades cualesquiera ni que consistencia o disponibilidad dejen de importar cuando no hay particiones. Describe compromisos bajo fallos de comunicación; define por operación qué lecturas y escrituras se pueden aceptar y cómo se recuperan los conflictos.

Empieza por las consultas y reglas de integridad que necesita el producto, el modelo de acceso a los datos, las transacciones, el volumen y la forma de escalar. Una base relacional suele convenir cuando importan relaciones explícitas, consultas flexibles y transacciones entre registros. Un almacén de documentos o clave-valor puede simplificar patrones de lectura conocidos y escalar ciertas cargas, pero impone otros compromisos de consulta, consistencia y modelado.

No elijas por etiquetas como “SQL no escala” o “NoSQL es más rápido”. Define el modelo con consultas reales, requisitos de consistencia, recuperación y operación, y mide con datos representativos.

El escalado vertical da más recursos a una instancia y suele ser sencillo, pero tiene límites y puede mantener un punto de falla común. El horizontal añade instancias para repartir carga y capacidad, aunque requiere resolver distribución de estado, balanceo, coordinación y fallos parciales.

Un servicio sin estado local suele ser más fácil de replicar; guarda sesiones y datos compartidos en sistemas apropiados. Mide primero el cuello de botella: añadir instancias no arregla una base de datos saturada, una contención global o una dependencia lenta.

Una SLI es una medida de una propiedad del servicio, como la proporción de solicitudes correctas y suficientemente rápidas. Un SLO fija el objetivo interno para esa medida durante una ventana de tiempo. Un SLA es un compromiso acordado con consecuencias definidas si no se cumple.

Elige indicadores que reflejen la experiencia del usuario y define cómo se miden, la ventana y el umbral. Un presupuesto de error expresa cuánto incumplimiento permite el SLO; puede orientar el equilibrio entre entregar cambios y reducir riesgos operativos.

La observabilidad permite inferir lo que ocurre dentro de un sistema a partir de sus señales. Métricas ayudan a ver tendencias y alertar; registros explican eventos concretos; trazas muestran el recorrido de una solicitud entre componentes. IDs de correlación y contexto consistente ayudan a relacionar esas señales.

Define qué preguntas operativas deben responderse, instrumenta los límites entre componentes y evita recolectar datos sensibles innecesarios. Más telemetría sin contexto, retención o alertas accionables aumenta costo y ruido en vez de mejorar el diagnóstico.

Una caché puede reducir latencia y lecturas repetidas cuando los datos se reutilizan con frecuencia y toleran una frescura definida. Con cache-aside, la aplicación consulta la caché, carga desde el origen cuando hay un fallo de caché y guarda el resultado; al actualizar, invalida o actualiza la entrada.

Define expiración, tamaño, invalidación y comportamiento si la caché falla. Anticipa estampidas cuando una clave popular expira y accesos a datos obsoletos. La guía de Microsoft sobre el patrón cache-aside explica sus beneficios y límites; la caché no debe ser la única copia de datos que no se puedan reconstruir.

Usa límites por usuario o servicio para que un cliente no consuma toda la capacidad; aplica backpressure para que los productores reduzcan o pausen el envío cuando se acumula trabajo. Una cola puede suavizar picos si el trabajo puede procesarse después y si se controla su tamaño y antigüedad.

Prioriza operaciones esenciales, degrada funciones opcionales cuando tenga sentido y devuelve una respuesta explícita para que el cliente sepa cuándo reintentar. La guía de Microsoft sobre throttling describe límites como una protección para sostener objetivos de servicio bajo carga.

Una operación idempotente produce el mismo efecto observable si se ejecuta una o varias veces con la misma solicitud. Esto importa porque una respuesta puede perderse después de que el servidor complete el trabajo; el cliente no siempre puede saber si es seguro repetirlo.

Para una operación de escritura, puedes aceptar una clave de idempotencia, guardar el resultado asociado y devolverlo en repeticiones. Limita la retención y vincula la clave a usuario y contenido. Los reintentos deben ser finitos, con demoras y variación, y solo aplicarse a fallos transitorios y operaciones seguras de repetir.

Evita asumir que una transacción de base de datos local puede abarcar servicios distribuidos con la misma garantía. Una saga divide el flujo en pasos locales y define acciones compensatorias para responder cuando un paso posterior falla. Puede coordinarse por eventos entre participantes o mediante un orquestador.

Diseña cada paso para duplicados, reintentos y resultados inciertos; registra el progreso y ofrece reconciliación cuando una compensación no pueda deshacer el efecto original. Las guías de Microsoft para transacciones compensatorias explican este enfoque y sus límites.

Event Sourcing conserva como registro principal la secuencia de eventos que produjo cambios de estado, y reconstruye el estado aplicándolos. Publicar un evento en una arquitectura orientada a eventos no implica que ese flujo sea el registro principal: muchos sistemas publican notificaciones y conservan su estado actual en una base convencional.

Event Sourcing puede ayudar con auditoría o reconstrucción histórica cuando esos requisitos lo justifican. Añade versionado de eventos, proyecciones, reconstrucciones, privacidad y complejidad operativa; no lo adoptes solo para “tener eventos”.

Prefiere cambios compatibles: agregar un campo opcional suele ser más seguro que quitar o cambiar el significado de uno existente. Mide qué versiones de clientes siguen activas, documenta el contrato y acuerda una política para avisar y retirar versiones.

Si el cambio es incompatible, publica una versión nueva y mantén la anterior durante una transición definida. Valida contratos entre productores y consumidores para descubrir incompatibilidades antes del despliegue. Microsoft resume estas prácticas en su guía de diseño de API y versionado.

Identifica activos, límites de confianza, entradas, identidades y dependencias; después enumera cómo podría abusarse de cada flujo y qué impacto tendría. Prioriza amenazas por probabilidad y daño, y añade controles verificables como autorización en el servidor, validación de entradas, mínimo privilegio, límites de solicitudes y auditoría.

Repite el análisis cuando cambien los límites o se agreguen integraciones importantes. La guía de modelado de amenazas de OWASP ofrece un proceso para estructurar esta revisión; el modelado no sustituye pruebas de seguridad ni respuesta a incidentes.

Clasifica datos por sensibilidad, recoge solo lo necesario y define quién puede acceder, durante cuánto tiempo y cómo se elimina. Usa cifrado en tránsito y en reposo donde corresponda, gestiona las claves por separado y evita que secretos o datos personales aparezcan en registros, trazas, capturas o copias de prueba.

Diseña controles para todo el ciclo de vida: creación, uso, transferencia, respaldo, restauración y eliminación. Las decisiones dependen de las obligaciones y amenazas reales; valida controles y permisos con pruebas, no solo con diagramas.

Usa despliegues graduales cuando el sistema lo permita: canary envía una fracción del tráfico a la versión nueva; blue-green mantiene dos entornos y cambia el tráfico tras comprobar el segundo. Compara indicadores acordados, detén la expansión si empeoran y conserva un procedimiento probado para volver atrás.

Una reversión de código no revierte automáticamente cambios de datos. Diseña compatibilidad entre versiones y migraciones para que el retroceso o una publicación por etapas no deje datos ilegibles. La estrategia debe ajustarse a los objetivos de recuperación y al costo de operar entornos paralelos.

Las pruebas unitarias validan lógica local; las de integración ejercitan dependencias reales o controladas; las de contrato detectan cambios incompatibles entre servicios; las de carga y resiliencia revelan límites de rendimiento y recuperación. Ninguna por separado demuestra que toda la arquitectura satisfaga cada atributo de calidad.

Automatiza reglas que deban seguir siendo ciertas —por ejemplo, límites de dependencias entre módulos o un presupuesto de latencia— y pruébalas en el pipeline adecuado. Mantén los escenarios representativos y separa fallos del código de la inestabilidad del entorno.

Para un cambio compatible, usa una secuencia de expansión y contracción: primero agrega el esquema nuevo de forma que lo tolere la versión existente; después despliega código que escriba o lea con compatibilidad; migra y valida los datos; por último elimina las columnas o rutas antiguas cuando ya no haya consumidores.

Haz la migración repetible o reanudable, limita el tamaño de lotes, observa errores y define cómo detener o continuar el proceso. Para cambios de alto riesgo, prueba restauración y recuperación antes de tocar producción.

Combina revisión de dependencias y cambios con señales de operación: modificaciones que siempre deben desplegarse juntas, cambios que requieren coordinar varios equipos, dependencias circulares, fallos que cruzan límites y tiempos de entrega.

Automatiza reglas arquitectónicas comprobables, revisa registros de decisiones cuando cambien los requisitos y vuelve a dibujar el sistema con evidencia reciente. Un límite útil facilita el cambio y contiene responsabilidades; no es un fin que deba conservarse si el dominio deja de respaldarlo.