🎯 Tácticas y patrones — Escalabilidad y Latencia

Proyecto	Solventa — Aseguradora digital
Elaboración	Juan Acevedo, John Guerrero, Mauricio Rodriguez, Martin Romero
Versión	1.0
Atributos priorizados	Escalabilidad y Latencia (desempeño)
Insumos	Enunciado MISW4501-202614-Proyecto.pdf · Hoja de trabajo (objetivos y escenarios EC-*)

---

1. Marco conceptual

Nivel	Qué es	Qué gobierna
Estilo arquitectónico	Decisión de primer nivel y alto grado de abstracción. Establece vocabulario, reglas y lineamientos sobre la topología del modelo y su semántica.	Determina qué atributos de calidad quedan intrínsecamente favorecidos o desfavorecidos.
Táctica arquitectónica	Técnica que modifica, refina y especializa un estilo en puntos y componentes específicos.	Asegura la respuesta y la medida de respuesta estipuladas en un escenario de calidad.
Patrón de diseño	Solución conocida a un problema recurrente de estructuración y asignación de responsabilidades entre clases y objetos.	Conecta la táctica con el código.

Familia de modelos	Qué hace evidente	Elementos
Módulo	Unidades de implementación (tiempo de desarrollo).	Clases, paquetes, capas; relaciones usa a / depende de.
Componente y Conector (C&C)	Ejecución en tiempo de corrida.	Componentes y conectores — el conector es el elemento determinante para el cumplimiento del atributo de calidad.
Asignación	Asignación de software a entidades del mundo real.	Despliegue (nodos), concurrencia (procesos/hilos), asignación de trabajo.

Catálogo de desempeño del curso. Desempeño = habilidad de cumplir requerimientos de tiempo; se subdivide en latencia (tiempo entre evento y respuesta) y escalabilidad (incrementar la carga sin perjudicar los tiempos de respuesta).

Familia I — control del acceso a recursos compartidos	Familia II — incremento y manejo de recursos disponibles
Manejo de la prioridad de los eventos	Introducción de concurrencia
Limitar la respuesta a los eventos	Múltiples copias de computación (horizontal)
Incrementar la latencia de los recursos	Incrementar los recursos de computación (vertical)
	Múltiples copias de datos

La utilización de un API gateway está catalogada por el material como táctica de disponibilidad (ocultar localización e instancias, enmascarar fallas), con uso complementario en seguridad.

---

2. Modelos de referencia

Las decisiones de este documento se sustentan sobre los siguientes modelos:

Modelo	Vista	Enlace
Modelo de componentes	Funcional — Componente y Conector	Ver diagrama
Modelo de despliegue	Asignación	Ver diagrama
Modelo de datos	Información	Ver diagrama

---

3. Estilos arquitectónicos

Estilo	Familia	Dónde vive	Favorece	Sacrifica
Microservicios	C&C	Dominio · Venta y Dominio · Operación como unidades desplegables con almacén propio	Escalabilidad selectiva, modificabilidad	Latencia de red interna, consistencia distribuida
Llamada-retorno sincrónico (N-niveles)	C&C	APISocios → :MsCotización → :MotorRaiting	Baja latencia y consistencia inmediata en el journey de venta	Acoplamiento temporal
Publicador-suscriptor (EDA)	C&C	:BusEventos → :Analitica, :Notificaciones, :Documentos; :ColaPagos tras :MsPagos; :TopicoTelemetria → :MotorParametrico	Escalabilidad: absorbe picos con contrapresión, admite consumidores nuevos sin tocar productores	Consistencia eventual, idempotencia
Capas + adaptadores (anticorrupción)	Módulo	:AdaptadorOF, :AdaptadorOD, :AdaptadorPasarela, :AdaptadorKYC, :AdaptadorTelemetria	Modificabilidad e integrabilidad	Una indirección más por llamada

Regla de reparto. Es síncrono lo que el usuario espera mirando la pantalla (cotizar, perfilar, suscribir, emitir). Es asíncrono lo que puede converger después (notificar, analizar, conciliar, telemetría paramétrica). Esa frontera es la decisión que más pesa sobre latencia y escalabilidad a la vez.

---

4. Tácticas de LATENCIA

Táctica (nombre del catálogo)	Familia	Modelo donde está presente	Componente del diagrama	Escenario
Múltiples copias de datos	II	Modelo C&C	:CacheOF, :CacheOD delante de :AdaptadorOF / :AdaptadorOD	EC-LAT-09 — p95 ≤ 250 ms resolviendo con valor de respaldo
Limitar la respuesta a los eventos	I	Modelo C&C	:MsPolizas confirma y publica en :BusEventos; firma y notificación salen del camino crítico. :ColaPagos entre :MsPagos y el flujo asíncrono	EC-LAT-05 / EC-LAT-06 — p95 ≤ 1,5 s · p99 ≤ 3 s
Introducción de concurrencia	II	Modelo de Asignación (concurrencia)	Fan-out paralelo de :MsPerfilamiento hacia :AdaptadorOF y :AdaptadorOD	EC-LAT-03 / EC-LAT-04 — p95 ≤ 400 ms · p99 ≤ 800 ms

Aritmética que justifica la concurrencia. EC-LAT-07 fija ≤ 120 ms por dependencia externa y EC-LAT-03 fija 400 ms para todo el perfilamiento. Invocar :AdaptadorOF y :AdaptadorOD en serie consume 240 ms de los 400; en paralelo, 120 ms. Es la única forma aritméticamente viable de cumplir el escenario.

Respuesta a la pregunta 3 del enunciado (¿cómo se protege el presupuesto de latencia de la cotización cuando depende de Open Finance?): no con el :ApiGateway —que añade un salto—, sino porque :CacheOF ya tiene el perfil y la llamada a :AdaptadorOF es una actualización oportunista, no una dependencia bloqueante. EC-LAT-08 corta a 700 ms y :MsCotización resuelve con el respaldo.

---

5. Tácticas de ESCALABILIDAD

Táctica (nombre del catálogo)	Familia	Modelo donde está presente	Componente del diagrama	Escenario
Múltiples copias de computación	II	Modelo de Asignación (despliegue)	Réplicas de :MsCotización + :MotorRaiting como grupo, separadas de :MsPerfilamiento + :MotorRiesgo	EC-ESC-01 — 500 → 50.000 cot/min sostenidas 30 min
Incrementar los recursos de computación	II	Modelo de Asignación (despliegue)	Nodos de :MotorRaiting / :MotorRiesgo (cómputo intensivo, poco estado)	EC-ESC-02 — capacidad ampliada ≤ 60 s
Introducción de concurrencia + contrapresión	II	Modelo C&C y de Asignación	:AdaptadorTelemetria → :TopicoTelemetria → :MotorParametrico con grupo de consumidores	EC-ESC-03 — ≥ 1.000.000 eventos en 10 min, con procesamiento exactamente una vez

Las dos primeras son decisiones de la familia de asignación: su evidencia se documenta en el modelo de despliegue, no en el de componentes.

Por qué :MsCotización y :MsPerfilamiento son componentes separados. No es modularidad estética: sus curvas de carga no coinciden. :MsCotización escala con la campaña de un socio (EC-ESC-01, pico inducido y previsible); :MsPerfilamiento escala con el cierre de mes de los bancos aliados (EC-LAT-04, pico de originación). Escalarlos juntos obliga a dimensionar por el máximo de ambos. Esta es la justificación de fondo del estilo de microservicios en este caso.

Cómo se combinan los dos escalamientos. El horizontal es la decisión por defecto, porque aporta elasticidad y tolerancia a la falla de una zona. El vertical se emplea sobre los motores de cálculo para ganar los primeros segundos de la rampa, donde el aprovisionamiento horizontal aún no ha terminado.

---

6. Tácticas de MODIFICABILIDAD y otras del catálogo

Los patrones de la sección siguiente aterrizan mayoritariamente tácticas de modificabilidad, no de desempeño. Se documentan aquí para que la trazabilidad táctica → patrón quede completa: cada patrón de §7 apunta a una táctica descrita en §4, §5 o en esta sección. No son los atributos priorizados, pero sostienen a los que sí lo son — el bajo acoplamiento, en particular, es precondición del escalamiento selectivo.

Táctica (nombre del catálogo)	Atributo	Modelo donde está presente	Componente del diagrama	Escenario
Reducción del acoplamiento	Modificabilidad	Modelo de Módulo	Interfaces provided/required entre componentes; :BusEventos como intermediario orientado a mensajes; capa :Adaptador*	EC-MOD-05 · EC-INT-03 · EC-INT-04
Mantener alta cohesión	Modificabilidad	Modelo de Módulo	Submódulos de Dominio · Venta y Dominio · Operación; cada motor separado de su orquestador	EC-MOD-01 · EC-MOD-03 · EC-MOD-04
Utilización de un API Gateway	Disponibilidad y seguridad	Modelo C&C	:ApiGateway con :APISocios, :BFFWeb, :BFFMovil, :ApiTelemetria	EC-INT-04 · EC-SEG-07

Por qué el bajo acoplamiento no es un tema secundario aquí. Solo se puede replicar de forma independiente aquello que no arrastra a sus vecinos. Si :MsCotización dependiera de la implementación de sus colaboradores, escalarla obligaría a escalarlos con ella y desaparecería la ventaja de tener curvas de carga separadas. Es decir: la táctica de modificabilidad es la que hace posible la de escalabilidad.

---

7. Patrones de diseño que aterrizan las tácticas

Cada patrón se presenta con la táctica que aterriza (descrita en §4, §5 o §6), el componente donde vive, el modelo que lo hace evidente, el escenario que sostiene y la razón por la que se tomó la decisión — no solo qué hace, sino qué alternativa se descartó y qué se aceptó a cambio.

---

1. Fachada (GoF)

Táctica que aterriza	Utilización de un API Gateway (disponibilidad y seguridad): ocultar la localización y disponibilidad de los microservicios y enmascarar fallas.
Componente del diagrama	:ApiGateway con :APISocios, :BFFWeb, :BFFMovil, :ApiTelemetria
Modelo donde está presente	Modelo C&C
Escenario	EC-INT-04 — evolución compatible de contratos multicanal
ASR	HA-31

Por qué esta decisión. Solventa expone su núcleo a cuatro canales con ciclos de vida independientes: una app móvil que queda instalada en el dispositivo del cliente, un portal web, más de treinta socios que integran una vez y no vuelven a tocar el código, y un flujo de telemetría. Sin un punto de entrada único, cada canal quedaría atado a la topología interna del backend: dividir un microservicio o cambiar su dirección obligaría a coordinar el redespliegue de apps ya instaladas y de integraciones de terceros que Solventa no controla. La alternativa —exponer los microservicios directamente— era más simple y más rápida, pero congelaba la estructura interna. Se aceptó un salto de red adicional en el camino crítico a cambio de poder reorganizar el backend sin romper contratos externos, y como beneficio secundario el punto único es donde se concentran el control de acceso y el enmascaramiento de fallas.

---

2. BFF — Backend for Frontend (patrón de canal)

Táctica que aterriza	Utilización de un API Gateway, especializada por canal. Protege además el presupuesto de latencia al agregar en el borde, aunque la agregación no es una táctica nombrada del catálogo de desempeño.
Componente del diagrama	:BFFWeb y :BFFMovil, separados de :APISocios
Modelo donde está presente	Modelo C&C
Escenarios	EC-INT-04 · EC-LAT-05
ASR	HA-31 · HA-05

Por qué esta decisión. Los tres canales no piden lo mismo. La web cubre la gestión completa del negocio; el móvil un subconjunto de tareas rápidas con evidencia, biometría y modo offline; los socios solo cotización y emisión embebidas. Una API única para los tres obligaría a servir el máximo común denominador, y el cliente compensaría la diferencia con varias llamadas encadenadas — un costo que se paga directamente contra el presupuesto de 1,5 s de EC-LAT-05. La alternativa era una sola API y clientes más gordos; se descartó porque traslada al canal un trabajo de composición que el borde hace mejor y más cerca de los datos. Se aceptó mantener tres piezas de borde en vez de una a cambio de que cada canal evolucione a su propio ritmo y de que la agregación ocurra donde no cuesta latencia.

---

3. Adaptador / Capa anticorrupción (GoF + DIP)

Táctica que aterriza	Reducción del acoplamiento (modificabilidad): usar APIs e intermediarios para que el dominio no dependa de la implementación del proveedor.
Componente del diagrama	:AdaptadorOF, :AdaptadorOD, :AdaptadorPasarela, :AdaptadorKYC, :AdaptadorTelemetria
Modelo donde está presente	Modelo de Módulo
Escenarios	EC-MOD-05 · EC-INT-03
ASR	HA-28 · HA-30

Por qué esta decisión. El enunciado es explícito en que gran parte del valor del negocio depende de integraciones fuera del control de Solventa, y que la regulación de Finanzas Abiertas sigue madurando. Sin una capa de traducción, el esquema de cada proveedor se filtraría hasta el dominio: los campos de Open Finance aparecerían dentro del motor de riesgo y los de la pasarela dentro de pagos. Ese acoplamiento convierte un cambio de proveedor —o un cambio normativo del proveedor— en un cambio transversal que toca varios componentes. Se aceptó una indirección adicional por llamada a cambio de que la sustitución de un tercero quede contenida en un solo módulo, que es exactamente lo que EC-MOD-05 exige medir.

---

4. Mediador (GoF)

Táctica que aterriza	Limitar la respuesta a los eventos (latencia, familia I) e introducción de concurrencia + contrapresión (escalabilidad, familia II).
Componente del diagrama	:BusEventos
Modelo donde está presente	Modelo C&C
Escenario	EC-ESC-03
ASR	HA-11

Por qué esta decisión. Un mismo hecho de negocio —una póliza emitida, un siniestro aprobado, un pago aplicado— le interesa a varios consumidores a la vez: analítica, notificaciones, documentos, y mañana fraude o reportes al regulador. Con comunicación punto a punto, cada consumidor nuevo obliga a modificar y redesplegar al productor, y la lista de consumidores solo crece con el negocio. El mediador invierte esa dependencia: el productor publica el hecho y deja de saber quién lo escucha. Se aceptó consistencia eventual —y la obligación de resolver idempotencia y trazabilidad— a cambio de poder sumar consumidores sin tocar productores y de absorber picos con contrapresión en lugar de propagarlos.

---

5. Singleton (GoF)

Táctica que aterriza	Es consecuencia obligada de Introducción de concurrencia (§4) y Múltiples copias de computación (§5), ambas de familia II: sin él, esas dos tácticas se anulan entre sí.
Componente del diagrama	Pool de conexiones dentro de cada réplica de :MotorRaiting y :MotorRiesgo
Modelo donde está presente	Modelo de Asignación (concurrencia y despliegue)
Escenarios	EC-LAT-03 · EC-ESC-01
ASR	HA-03 · HA-09

Por qué esta decisión. No es una elección estética: es la consecuencia obligada de haber adoptado concurrencia. La táctica de introducción de concurrencia multiplica los hilos dentro de cada réplica, y la de múltiples copias de computación multiplica las réplicas. Si cada hilo abriera su propio pool, las conexiones contra el almacén crecerían como hilos × réplicas — con 4 hilos y 20 réplicas son 80 pools golpeando la misma base. La contienda que se eliminó en el cómputo reaparecería en la persistencia, y las dos tácticas de escalamiento se anularían entre sí. Una única instancia por proceso acota las conexiones y deja que el paralelismo escale sin castigar el almacén.

---

6. Experto (GRASP)

Táctica que aterriza	Mantener alta cohesión (modificabilidad). Protege además el presupuesto de las tácticas de latencia al eliminar un salto de red del camino crítico.
Componente del diagrama	:MotorRiesgo decide sobre el perfil; :MotorParametrico sobre el umbral
Modelo donde está presente	Modelo de Módulo
Escenario	EC-LAT-03 — p95 ≤ 400 ms
ASR	HA-03

Por qué esta decisión. En una arquitectura distribuida cada decisión que se toma lejos de su dato cuesta un viaje de red, y ese viaje se descuenta de un presupuesto de 400 ms del que 120 ms ya están comprometidos por dependencia externa. La alternativa natural —un motor de reglas central que decidiera por todos los dominios— habría sido más fácil de gobernar, pero obligaría a que perfilamiento le enviara el perfil completo y esperara, y convertiría ese motor en cuello de botella común y en punto único de acoplamiento. Se prefirió pagar en gobierno (dos motores en vez de uno) para no pagar en latencia, poniendo cada decisión pegada al componente que ya tiene la información para tomarla.

---

7. Alta Cohesión (GRASP)

Táctica que aterriza	Mantener alta cohesión (modificabilidad): que las responsabilidades de cada componente estén ligadas a un único propósito.
Componente del diagrama	Paquete Dominio · Venta; :MotorRaiting como única razón de cambio del precio
Modelo donde está presente	Modelo de Módulo
Escenario	EC-MOD-03 — regla de precio
ASR	HA-26

Por qué esta decisión. El precio y la política de aceptación de riesgo cambian con una frecuencia que dicta actuaría, no ingeniería, y cambian por razones distintas entre sí. Si esa lógica viviera dentro de los orquestadores, cada ajuste de fórmula obligaría a redesplegar la cotización completa y a arrastrar en el mismo despliegue código que no cambió. Se separó el motor de quien lo orquesta para que la unidad de cambio coincida con la unidad de despliegue, que es la condición que EC-MOD-03 mide: el 100 % del cambio se despliega sin tocar componentes ajenos al motor de rating.

---

8. Bajo Acoplamiento (GRASP)

Táctica que aterriza	Reducción del acoplamiento (modificabilidad). Es precondición de múltiples copias de computación: solo se replica de forma independiente lo que no arrastra a sus vecinos.
Componente del diagrama	Interfaces provided/required entre componentes; :BusEventos como intermediario; capa de adaptadores
Modelo donde está presente	Modelo de Módulo
Escenarios	EC-MOD-05 · EC-INT-04
ASR	HA-28 · HA-31

Por qué esta decisión. El bajo acoplamiento se suele justificar solo por modificabilidad, pero en este caso es precondición de los dos atributos priorizados: solo se puede replicar de forma independiente aquello que no arrastra a sus vecinos. Si :MsCotización dependiera de la implementación de sus colaboradores, escalarla obligaría a escalarlos con ella y desaparecería la ventaja de tener curvas de carga separadas. Por eso se aplicaron los tres mecanismos del catálogo a la vez —interfaz, intermediario orientado a mensajes y adaptador— en lugar de conformarse con uno. Se aceptó más piezas y más contratos que mantener a cambio de que el escalamiento selectivo sea realmente posible.

---

9. Inversión de dependencias (SOLID)

Táctica que aterriza	Reducción del acoplamiento (modificabilidad), en su forma más estricta: el dominio no controla el ciclo de vida de su colaborador.
Componente del diagrama	Contratos entre el dominio y la capa de adaptadores
Modelo donde está presente	Modelo de Módulo
Escenarios	EC-MOD-05 · EC-INT-03
ASR	HA-28 · HA-30

Por qué esta decisión. Tener adaptadores no basta: si el dominio conociera al adaptador concreto y controlara su creación, seguiría atado a una implementación y el beneficio se perdería en el primer cambio de proveedor. Invertir la dependencia significa que el dominio declara qué necesita y recibe una abstracción ya construida, sin saber quién la implementa ni gestionar su ciclo de vida. Ese detalle es lo que convierte la contención del cambio en una propiedad verificable: por eso EC-MOD-05 puede exigir que el 100 % del cambio quede dentro del módulo de integración, y EC-INT-03 que el 100 % de los consumidores existentes siga operando sin modificación.

---

10. Creador (GRASP)

Táctica que aterriza	Reducción del acoplamiento (modificabilidad): concentrar la creación en un solo responsable evita que varios objetos dependan entre sí para instanciarse.
Componente del diagrama	:MsCotización crea la oferta; :MsSiniestros crea la evidencia y la evaluación
Modelo donde está presente	Modelo de Módulo y modelo de dominio
Escenario	EC-MOD-01
ASR	HA-25

Por qué esta decisión. En una arquitectura de microservicios con base de datos por servicio, la pregunta de quién instancia cada entidad no es un detalle de código: determina qué servicio es dueño de su ciclo de vida y, por lo tanto, de su almacén. Si un componente ajeno creara la evidencia de un siniestro, tendría que conocer el estado de la reclamación y quedaría acoplado al servicio que la gobierna, rompiendo la frontera del dato. Aplicar la regla de que crea quien contiene y usa estrechamente al objeto confina el ciclo de vida de cada entidad a su microservicio, que es la precondición del almacén propio por servicio y de la trazabilidad entre las tres vistas: componente que crea → entidad de dominio → esquema propietario.

---

11. Única Responsabilidad (SRP) y Abierto/Cerrado (OCP)

Táctica que aterriza	Mantener alta cohesión y reducción del acoplamiento (modificabilidad): unidades pequeñas, con una sola razón de cambio y un punto de extensión propio.
Componente del diagrama	Tres pares orquestador / motor: :MsCotización–:MotorRaiting, :MsPerfilamiento–:MotorRiesgo, :MsSiniestros–:MotorParametrico
Modelo donde está presente	Modelo de Módulo
Escenarios	EC-MOD-01 · EC-MOD-04
ASR	HA-25 · HA-27

Por qué esta decisión. El negocio de Solventa crece incorporando ramos: viaje, dispositivos, microseguros de vida, paramétricos, protección de pagos. Si cada ramo nuevo obligara a modificar los orquestadores, el costo de crecer aumentaría con el tamaño del portafolio y la meta de expansión regional se volvería inviable. Al concentrar la variabilidad del negocio en los motores, cada motor tiene una sola razón de cambio (SRP) y a la vez es el único punto por donde el producto se extiende (OCP). Son las dos caras de la misma decisión: lo que hace barato modificar es exactamente lo que hace barato extender. Que el patrón aparezca tres veces, y no una, es lo que lo convierte en principio aplicado y no en coincidencia.

---

8. Trade-offs asumidos

Un trade-off es lo que se sacrifica para conseguir algo. Ninguna decisión mejora todos los atributos a la vez; lo que sigue no son defectos ni deuda pendiente, sino decisiones conscientes con su mitigación.

Decisión	Se gana	Se sacrifica	Mitigación
Microservicios sobre monolito modular	Escalamiento selectivo por curva de carga	Latencia de red interna, complejidad operativa	Presupuesto de latencia por salto; fronteras alineadas con capacidades de negocio para evitar el monolito distribuido
:BusEventos para el flujo paramétrico	Absorción de picos; consumidores nuevos sin tocar productores	Consistencia eventual	Idempotencia por clave de evento
:CacheOF / :CacheOD en el camino crítico	Presupuesto protegido ante terceros degradados	Decidir con datos menos frescos	TTL por fuente + linaje de toda cotización resuelta con respaldo
:ColaPagos solo en :MsPagos, no en los demás dominios	Durabilidad y reintento idempotente donde se mueve dinero	Asimetría respecto de los demás recorridos	Es deliberada: el flujo de dinero exige durabilidad y aplicación exactamente una vez, exigencia que los demás recorridos no tienen
:ApiGateway como punto único	Enmascaramiento de fallas y superficie de ataque reducida	Un salto extra en el camino crítico y un punto de congestión	Replicado y multi-zona; sin lógica de negocio en el gateway
Escalamiento horizontal como decisión por defecto	Elasticidad y tolerancia a la falla de una zona	Mayor tiempo de aprovisionamiento en la rampa inicial	Escalamiento vertical de los motores de cálculo para cubrir los primeros segundos del pico

---

Fuentes

• Enunciado del caso: files/MISW4501-202614-Proyecto.pdf — §4 Ecosistema de integraciones, §6.1 Latencia, §6.2 Escalabilidad, §8 Decisiones de arquitectura, §9 Preguntas de discusión.
• Hoja de trabajo — objetivos de negocio y escenarios de calidad EC-*.
• Visión de arquitectura — modelos de contexto, dominio, componentes, datos y despliegue.