Isolation

Qué efecto se quiere contener

Isolation examina qué efectos, fallos, recursos o consecuencias de ejecución deben mantenerse contenidos entre unidades arquitectónicas. Decir «aislado» es incompleto: hay que indicar aislado de qué, mediante qué frontera y con qué límites.

El análisis parte de un efecto y de una población que necesita protección. «Payments lento no debe agotar todos los recursos de Orders» es una intención verificable; «son servicios separados» describe una realización sin demostrar el resultado. La contención puede ser parcial y distinta para cada efecto.

Es una dimensión de architecture-decision-axes, no un estilo, tecnología ni nivel de madurez. monolith, modular-monolith, service-based-architecture, service-oriented-architecture y microservices admiten decisiones de aislamiento diferentes. Ninguno ofrece todas las formas de contención automáticamente.

Decomposition y Deployment responden otras preguntas

decomposition identifica unidades y responsabilidades. Orders y Payments pueden tener código encapsulado y compartir heap, runtime, pool de conexiones y base de datos. boundaries aclara qué regla marca esa separación; un fallo de memoria o agotamiento del pool puede atravesar una frontera lógica sin violar encapsulación.

deployment pregunta qué se instala, actualiza o revierte como unidad; esa frontera no demuestra contención de efectos. Dos artefactos entregados por separado pueden depender del mismo broker o servidor de datos. También un solo artefacto puede disponer de pools y límites internos que contengan algunos consumos.

Separar proceso, container, servicio o deployment no garantiza aislamiento frente a todos los efectos. Un proceso con espacio de memoria propio limita algunas interferencias directas; no protege por sí solo del fallo de su nodo, saturación de storage o dependencia remota indisponible.

Place Order: proteger sin inventar independencia

El ejemplo mantiene Orders, Payments, Inventory y Shipping. Orders necesita una reserva y una autorización válidas para confirmar; Shipping necesita una solicitud permitida para iniciar el envío. Esa dependencia de resultado continúa existiendo.

Queremos evitar que la degradación de Payments consuma todos los recursos de Orders. Podemos limitar trabajo pendiente hacia Payments y preservar capacidad para consultar pedidos o procesar otros casos elegibles. Esto no convierte un pedido sin autorización en confirmado ni permite enviar ignorando su política.

El objetivo tiene dos partes: contener la propagación técnica y mantener semántica correcta. Una respuesta controlada de «pendiente» o «no disponible» puede preservar recursos sin completar la operación afectada. Las funcionalidades que sí continúan deben identificarse explícitamente.

Fallos y blast radius

Fault isolation busca impedir o acotar la propagación de un fallo. blast-radius describe el alcance de sus efectos; cascading-failures examina cómo el deterioro puede propagarse y amplificarse. Son relaciones fuertes, no conceptos intercambiables.

Una caída de Payments puede convertirse en un fallo amplio si Orders acumula trabajo, Inventory recibe reintentos innecesarios y Shipping pierde acceso al mismo pool. Contener solo el proceso inicial no protege las rutas de propagación.

Google SRE muestra cómo sobrecarga y agotamiento de recursos reducen trabajo útil y trasladan problemas a otros dominios. Este documento usa esa evidencia para preguntar dónde se detiene el efecto, no para asumir una frontera infalible. Google SRE, Addressing Cascading Failures.

Una intención de aislamiento necesita un modelo de fallo: lentitud, caída, carga excesiva o corrupción no exigen necesariamente la misma protección. Probar solo un error rápido no demuestra contención cuando la dependencia nunca responde.

Recursos y performance

Resource isolation examina qué capacidad se comparte, particiona o limita: CPU, memoria, threads, pools de conexiones, colas, IOPS de storage y cuotas o rate limits. Son recursos relacionados, pero reservar uno no reserva automáticamente los restantes.

Orders y Reporting pueden tener módulos separados y usar el mismo pool de base de datos. Si el batch de Reporting ocupa todas las conexiones, Orders queda bloqueado sin violación de su interfaz de código. Separar pools puede proteger conexiones y dejar compartidos CPU, locks e I/O del servidor.

Performance isolation pregunta si una carga degrada otra más allá de límites aceptables. Un pool propio no prueba ese resultado si ambas cargas compiten por storage. La evidencia necesita tráfico competidor, capacidad disponible y medidas de latencia o trabajo útil.

Foco	Pregunta en el ejemplo
Fault isolation	¿Payments fallido arrastra otras capacidades?
Resource isolation	¿Qué capacidad puede monopolizar Payments?
Performance isolation	¿Cuánto degrada otra carga a Orders?
Execution separation	¿Qué comparte cada entorno de ejecución?

Reservas demasiado pequeñas pueden rechazar trabajo con capacidad ociosa en otro grupo; compartir todo permite mayor uso y más interferencia. scaling pregunta qué capacidad puede cambiar independientemente: un pool delimitado puede mantener límites comunes de CPU o storage. La elección depende de prioridades y patrones de carga, no de una regla universal de partición.

Bulkhead como mecanismo, no como eje completo

bulkhead divide recursos o cargas para contener interferencia. Pools diferenciados para llamadas a Payments e Inventory pueden limitar cuánto trabajo bloqueado de un destino consume la capacidad del otro. Es una aplicación concreta dentro de Isolation.

Azure Architecture Center describe particiones de consumidores, servicios y recursos, e indica evaluar nivel de protección y overhead. El mecanismo requiere escoger la frontera y no sustituye toda protección frente a fallos compartidos. Azure, Bulkhead pattern.

Un bulkhead de threads no protege automáticamente el broker común, la memoria global o credenciales compartidas. Tampoco recupera una autorización ya realizada. Sus límites pueden combinarse con políticas de admisión y espera, sin que este eje duplique los canonicals operacionales.

Dominios de fallo que se superponen

Un failure domain es un ámbito donde un fallo común puede afectar varias unidades o recursos. Puede corresponder a proceso, nodo, zona, base de datos, broker cluster, proveedor de credenciales o segmento de red. Es una propiedad relativa al fallo considerado.

Dos servicios en nodos distintos pueden compartir base de datos; dos bases distintas pueden compartir storage o credenciales. Esos ámbitos se superponen, sin formar necesariamente una jerarquía única. Un diagrama de procesos no muestra todos los puntos comunes.

Microservices puede aumentar separación de ejecución, pero un nodo compartido, cache, identity provider, red o cuota de cuenta puede mantener riesgos conjuntos. Contenedores diferentes no implican necesariamente capacidad reservada ni hosts independientes.

La infraestructura compartida tampoco elimina toda posibilidad de aislamiento: límites, cuotas, pools y particiones pueden contener consumos específicos. Se debe registrar qué permanece común y qué fallo supera la protección, en lugar de afirmar protección total o ausencia total.

Datos, seguridad y cambios

data-ownership establece autoridad sobre estado. Data isolation examina separación o contención de acceso y efectos sobre datos. Inventory puede ser autoridad lógica del stock y compartir un servidor cuya caída afecta Orders; ownership claro no demuestra aislamiento físico fuerte.

Permisos de proceso, trust boundaries, alcance de credenciales y fronteras de red contribuyen a security isolation. Separar ejecución con credenciales idénticas y acceso amplio puede conservar autoridad técnica para afectar datos ajenos. No basta contar procesos para concluir que existe protección de seguridad.

Encapsular representación también limita propagación de cambios y favorece modifiability. Esa relación es secundaria aquí: aislamiento de cambios no significa contención de crashes, carga o memoria. Conviene nombrar cada propiedad para no convertir Isolation en sinónimo de toda buena modularidad.

Monolith y servicios separados: límites concretos

Un Modular Monolith puede proteger interfaces y cambios entre módulos mientras comparte runtime. Pools, colas y límites internos aportan contención parcial de recursos; un crash de proceso o presión de memoria global aún puede afectar el conjunto.

Servicios separados pueden limitar un crash local y conservar coupling a recursos comunes. Una actualización incompatible de un contrato también puede afectar operaciones sin atravesar memoria. La decisión debe especificar qué protección agrega la separación y qué costos de comunicación y operación introduce.

Isolation no es independence. Un Payments protegido en CPU puede seguir siendo semánticamente necesario para confirmar Orders. A la inversa, pocas dependencias de código no protegen de un pool compartido agotado. dependency-structure ayuda a examinar esas obligaciones sin confundirlas con contención.

Interacciones y evidencia arquitectónica

Mayor separación puede hacer más costosa coordination: los participantes dejan de apoyarse en memoria, locks o transacciones compartidos y requieren protocolos, mensajes y recuperación. Compartir esos mecanismos simplifica ciertos acuerdos locales y puede ampliar el blast radius.

Autoridades de datos delimitadas pueden contener escrituras indebidas y cambios de schema. Bases físicamente separadas agregan superficie operativa y necesidades de coordinación o copias. Ni separar todo ni compartir todo constituye una recomendación universal.

operability necesita distinguir el componente degradado de los síntomas propagados. cost-efficiency incluye capacidad reservada, particiones, monitoreo y esfuerzo de pruebas. La protección útil es la que sostiene los objetivos elegidos con costos conocidos.

Para Place Order, ensayar Payments sin respuesta y Reporting bajo carga. Medir recursos pendientes, operaciones que continúan y límites superados. Asegurar que el workflow conserve resultados legales. Un escenario concreto permite comprobar protección; una etiqueta arquitectónica solo indica dónde empezar a investigarla.

tenancy examina cómo clientes comparten o separan estado, acceso y capacidad. Tenant isolation es una aplicación posible de Isolation, no su definición. Este eje también protege capacidades, dependencias y cargas dentro del mismo cliente.