Experimentos de arquitectura - JuanHerreraP/Proyecto-MISO-Solventa-Grupo-11 GitHub Wiki

Experimento 1 - Latencia del perfilamiento mediante Cache-Aside

Descripción del experimento

Elemento Descripción
Título del experimento Validación de latencia del perfilamiento mediante Cache-Aside
Propósito del experimento Validar si la utilización de una caché de perfiles permite disminuir el impacto de las consultas a Open Finance y Open Data sobre el tiempo total de perfilamiento. El punto de sensibilidad corresponde al uso de la información almacenada en Redis antes de realizar una consulta a los proveedores externos.
Resultados esperados El sistema debe generar el perfil de riesgo individualizado y el precio personalizado cumpliendo el escenario EC02: p95 ≤ 400 ms y p99 ≤ 800 ms. Se comparará el comportamiento cuando el perfil se encuentra disponible en caché frente al escenario en el que es necesario consultar las fuentes externas.
Recursos requeridos Servicio de Perfilamiento y servicio de Cotización desarrollados con FastAPI, ElastiCache Redis, adaptadores de Open Finance y Open Data, servicios externos simulados, ambiente AWS y k6 para generación de carga y medición de tiempos de respuesta.
Elementos de arquitectura involucrados ASR: EC02 - Latencia.

Vistas involucradas: Vista funcional general y Vista de despliegue.

Elementos: Perfilamiento de Riesgo, Cotización y Precio, ElastiCache Redis y adaptadores de Open Finance/Open Data.

Punto de sensibilidad: consulta y reutilización del perfil almacenado en caché antes de realizar las llamadas a proveedores externos.
Esfuerzo estimado 24 horas-hombre como estimación inicial propuesta, distribuidas entre los cuatro integrantes.

Hipótesis de diseño

Elemento Hipótesis de diseño
Punto de sensibilidad Uso del perfil almacenado en ElastiCache Redis antes de realizar nuevas consultas a Open Finance y Open Data.
Hipótesis de diseño Si Solventa utiliza el patrón Cache-Aside con ElastiCache Redis para reutilizar perfiles de riesgo vigentes, entonces el proceso de perfilamiento podrá cumplir EC02, manteniendo p95 ≤ 400 ms y p99 ≤ 800 ms, al disminuir las consultas que dependen directamente de los proveedores externos.
Historia de arquitectura asociada EC02 - Latencia: perfilamiento y personalización dentro del recorrido de compra del seguro de vida hipotecario.
Nivel de incertidumbre Alto. La arquitectura contempla el uso de caché para reducir la dependencia de los proveedores externos, pero aún no se cuenta con resultados experimentales que demuestren que esta decisión permite alcanzar los percentiles definidos en EC02.

Patrones de Arquitectura asociados al experimento

Patrón de Arquitectura asociado al experimento Descripción
Patrón 6: Cache‐Aside El servicio de Perfilamiento consulta primero ElastiCache Redis. Si encuentra un perfil vigente, utiliza esta información. Si no existe, consulta Open Finance/Open Data mediante sus adaptadores y posteriormente almacena el resultado en la caché.

Tácticas de Arquitectura asociadas al experimento

Táctica de Arquitectura asociada al experimento Descripción
Maintain multiple copies of data or computations Táctica de performance orientada a mantener copias de datos o cálculos para disminuir contención y tiempo de respuesta. En Solventa se concreta mediante la copia temporal del perfil de riesgo almacenada en ElastiCache Redis, evitando repetir una consulta externa cuando existe información vigente.

Listado de componentes involucrados en el experimento

Microservicio / Componente Propósito y comportamiento esperado Tecnología asociada
Perfilamiento de Riesgo Generar el perfil de riesgo del cliente. Debe consultar primero la información disponible en caché y recurrir a las fuentes externas cuando sea necesario. Python + FastAPI / ECS Fargate
Cotización y Precio Utilizar el perfil de riesgo para generar el precio personalizado de la oferta. Python + FastAPI / ECS Fargate
Adaptador Open Finance Traducir las solicitudes del dominio al contrato del proveedor de Open Finance cuando sea necesaria una consulta externa. AWS Lambda
Adaptador Open Data Traducir las solicitudes del dominio al contrato de las fuentes de Open Data cuando sea necesaria una consulta externa. AWS Lambda

Listado de conectores involucrados en el experimento

Conector Comportamiento deseado en el experimento Tecnología asociada
Solicitud de perfilamiento Recibir la solicitud y retornar el resultado dentro de los tiempos establecidos por EC02. HTTP/HTTPS - API REST
Perfilamiento - Caché Consultar si existe un perfil vigente y recuperar la información cuando corresponda. ElastiCache Redis
Perfilamiento - Adaptadores externos Realizar la consulta externa únicamente cuando la información requerida no se encuentre disponible en caché. Comunicación hacia adaptadores AWS Lambda
Adaptador - Proveedor externo simulado Permitir simular respuestas de Open Finance y Open Data con tiempos de respuesta controlados para observar su impacto sobre el perfilamiento. HTTP/HTTPS - Mock/Stub

Tecnología asociada con el experimento

Tecnología asociada con el experimento Justificación
Lenguajes de programación Python, definido para los servicios backend de Solventa.
Plataforma de despliegue AWS ECS Fargate para los servicios de dominio y AWS Lambda para los adaptadores externos, de acuerdo con la vista de despliegue.
Bases de datos / almacenamiento PostgreSQL y ElastiCache Redis, utilizado por la arquitectura como caché de perfiles y cotizaciones.
Herramientas de análisis k6, definido en la estrategia de pruebas para validar los escenarios de latencia y escalabilidad EC01-EC04.
Librerías redis (redis-py) para implementar la comunicación del servicio de Perfilamiento con ElastiCache Redis; httpx para las llamadas HTTP hacia los adaptadores/proveedores simulados; pytest y pytest-asyncio para automatizar los escenarios de cache hit, cache miss, expiración y respuesta de proveedores externos.
Frameworks de desarrollo FastAPI, framework definido para los servicios backend de Solventa.

Interpretación de resultados

Resultado obtenido Interpretación
p95 ≤ 400 ms y p99 ≤ 800 ms La evidencia obtenida soporta la hipótesis de que el uso de Cache-Aside permite cumplir EC02 bajo las condiciones evaluadas.
p95 > 400 ms o p99 > 800 ms La hipótesis no queda validada bajo las condiciones del experimento y será necesario revisar la decisión de diseño o su configuración.
El requisito se cumple únicamente cuando existe información en caché El experimento evidencia que la estrategia es efectiva para cache hits, pero también muestra una sensibilidad importante frente a los cache misses y las consultas a los proveedores externos. Esta condición deberá documentarse como resultado del experimento.

Distribución de actividades por integrante

Integrante Tareas a realizar Esfuerzo estimado
Ana María Solano Preparar los escenarios del experimento y el script de carga en k6; consolidar las métricas p95 y p99. 6 h*
Juan Esteban Herrera Preparar el servicio de Perfilamiento y el flujo de consulta hacia ElastiCache Redis. 6 h*
Harold Virguez Preparar los servicios simulados de Open Finance/Open Data y los escenarios con diferentes tiempos de respuesta. 6 h*
Fernando Parra Preparar el ambiente de ejecución y consolidar las métricas obtenidas durante las pruebas. 6 h*
Total 24 h*

*Estimación inicial

Experimento 2 - Escalabilidad del servicio de cotización

Descripción del experimento

Elemento Descripción
Título del experimento Validación del autoescalado del servicio de Cotización y Precio
Propósito del experimento Validar si el despliegue del servicio de Cotización y Precio en ECS Fargate con autoescalado permite incrementar su capacidad frente a una campaña masiva de un socio. El punto de sensibilidad corresponde a la cantidad de recursos y réplicas disponibles para atender el incremento de solicitudes.
Resultados esperados Cumplir EC03: escalar de 500 a 50.000 cotizaciones por minuto, conservando el p95 de latencia y logrando que el autoescalado agregue capacidad en ≤ 60 segundos.
Recursos requeridos Servicio de Cotización y Precio desarrollado con FastAPI, API Gateway, Application Load Balancer, ECS Fargate, ECS Auto Scaling, ambiente AWS y k6 para generación de carga.
Elementos de arquitectura involucrados ASR: EC03 - Escalabilidad.

Vista involucrada: Vista de despliegue.

Elementos: API Gateway, Application Load Balancer, Distribución y Socios, Cotización y Precio y ECS Fargate con autoescalado.

Punto de sensibilidad: cantidad y capacidad de las réplicas disponibles para procesar solicitudes de cotización frente a un incremento súbito de carga.
Esfuerzo estimado 24 horas-hombre como estimación inicial propuesta, distribuidas entre los cuatro integrantes.

Hipótesis de diseño

Elemento Hipótesis de diseño
Punto de sensibilidad Cantidad de recursos y réplicas del servicio de Cotización y Precio disponibles ante el crecimiento súbito del tráfico.
Hipótesis de diseño Si el servicio de Cotización y Precio se ejecuta como un servicio sin estado sobre ECS Fargate y puede aumentar horizontalmente el número de réplicas disponibles, entonces Solventa podrá incrementar su capacidad de 500 a 50.000 cotizaciones/minuto, conservando el p95 de latencia y agregando capacidad en ≤ 60 segundos.
Historia de arquitectura asociada EC03 - Escalabilidad: un socio de distribución lanza una promoción que incrementa 100 veces el tráfico de cotizaciones.
Nivel de incertidumbre Alto. La arquitectura define ECS Fargate con autoescalado, pero es necesario comprobar experimentalmente si el incremento de capacidad ocurre dentro de los 60 segundos exigidos y si el p95 se conserva durante el pico.

Patrones de Arquitectura asociados al experimento

Patrón de Arquitectura asociado al experimento Descripción
Patrón 7: Redundancia Multi‐AZ y Autoescalado Los servicios de Solventa se ejecutan mediante ECS Fargate y pueden mantener múltiples réplicas. ECS Auto Scaling aumenta o disminuye la cantidad de réplicas según la carga, mientras el Application Load Balancer distribuye las solicitudes entre las instancias disponibles.

Tácticas de Arquitectura asociadas al experimento

Táctica de Arquitectura asociada al experimento Descripción
Introduce concurrency Permite procesar múltiples solicitudes en paralelo, reduciendo el tiempo bloqueado cuando varias solicitudes compiten por capacidad de procesamiento. En el experimento se concreta mediante múltiples tareas de ECS Fargate procesando solicitudes simultáneamente.
Maintain multiple copies of data or computations La táctica permite mantener múltiples copias de una computación para disminuir contención sobre un único recurso. En Solventa se materializa mediante varias réplicas del servicio de Cotización y Precio ejecutándose en ECS Fargate.
Increase available resources Consiste en aumentar los recursos disponibles para atender la demanda. En el experimento se aplica mediante ECS Auto Scaling, que incrementa la cantidad de tareas disponibles ante el crecimiento del tráfico.

Listado de componentes involucrados en el experimento

Microservicio / Componente Propósito y comportamiento esperado Tecnología asociada
Distribución y Socios Atender las solicitudes originadas por los socios de distribución y dirigirlas hacia los servicios de dominio requeridos. Python + FastAPI / ECS Fargate
Cotización y Precio Procesar las solicitudes de cotización y permitir que su capacidad aumente horizontalmente mediante múltiples réplicas. Python + FastAPI / ECS Fargate

Listado de conectores involucrados en el experimento

Conector Comportamiento deseado en el experimento Tecnología asociada
Socio - API Gateway Recibir el incremento de solicitudes generado durante el experimento. HTTPS / AWS API Gateway
API Gateway - Application Load Balancer Enrutar las solicitudes recibidas hacia la capa de cómputo de Solventa. AWS API Gateway / ALB
Application Load Balancer - ECS Fargate Distribuir las solicitudes entre las réplicas disponibles del servicio. AWS Application Load Balancer
Métricas - ECS Auto Scaling Permitir que la política de escalamiento aumente el número de tareas disponibles cuando la carga lo requiera. AWS ECS Auto Scaling / métricas de AWS

Tecnología asociada con el experimento

Tecnología asociada con el experimento Justificación
Lenguajes de programación Python, definido para los servicios backend de Solventa.
Plataforma de despliegue AWS ECS Fargate, plataforma de cómputo con autoescalado.
Bases de datos PostgreSQL
Herramientas de análisis k6, definido para las pruebas de carga de EC01-EC04. Las métricas de AWS permitirán observar la cantidad de tareas y el comportamiento del escalamiento.
Librerías No se requiere una librería adicional específica definida actualmente en la arquitectura para realizar el experimento de autoescalado.
Frameworks de desarrollo FastAPI, framework utilizado para los servicios backend.

Interpretación de resultados

Resultado obtenido Interpretación
50.000 cotizaciones/min, p95 conservado y capacidad agregada en ≤ 60 s La evidencia obtenida soporta la hipótesis y permite considerar satisfecha la respuesta esperada de EC03 bajo las condiciones del experimento.
Se alcanzan 50.000 cotizaciones/min, pero se degrada el p95 La capacidad aumenta, pero la hipótesis no se valida completamente porque EC03 exige conservar el p95.
El autoescalado requiere más de 60 s La hipótesis no se valida respecto al tiempo de reacción definido en EC03.
No se alcanza la carga objetivo La capacidad o configuración utilizada no es suficiente para satisfacer EC03 y deberá revisarse la decisión o configuración arquitectónica.

Distribución de actividades por integrante

Integrante Tareas a realizar Esfuerzo estimado
Ana María Solano Preparar el escenario de carga en k6 y configurar el incremento desde la carga inicial hasta la carga objetivo. 6 h*
Juan Esteban Herrera Preparar el servicio de Cotización y Precio y verificar su ejecución mediante múltiples réplicas. 6 h*
Harold Virguez Preparar la configuración de ECS Fargate y ECS Auto Scaling requerida para ejecutar el experimento. 6 h*
Fernando Parra Ejecutar el experimento, consolidar tiempos de escalamiento, p95, throughput y resultados. 6 h*
Total 24 h*

*Estimación inicial.

Experimento 3 - Facilidad de modificación mediante Puertos y Adaptadores

Descripción del experimento

Elemento Descripción
Título del experimento Validación del aislamiento de cambios de proveedor mediante Puertos y Adaptadores
Propósito del experimento Validar si la utilización de Puertos y Adaptadores permite sustituir un proveedor KYC sin propagar cambios hacia el servicio de Identidad y los demás componentes consumidores. El punto de sensibilidad corresponde al contrato definido entre el dominio y el adaptador externo.
Resultados esperados El proveedor KYC debe poder sustituirse modificando o incorporando únicamente el adaptador correspondiente y su configuración, manteniendo cero cambios en los componentes consumidores, de acuerdo con el criterio disponible de EC06.
Recursos requeridos Servicio de Identidad, KYC y Consentimiento, puerto IdentityVerificationProvider, adaptador KYC, dos proveedores KYC simulados con contratos diferentes, Pytest y GitHub Actions para ejecutar las pruebas de regresión.
Elementos de arquitectura involucrados ASR: EC06 - Facilidad de modificación.

Vistas involucradas: Vista funcional general y Vista de despliegue.

Elementos: Identidad, KYC y Consentimiento; IdentityVerificationProvider; Adaptador KYC y proveedor KYC.

Punto de sensibilidad: estabilidad de la interfaz interna utilizada por el dominio frente al cambio de proveedor externo.
Esfuerzo estimado 24 horas-hombre como estimación inicial propuesta, distribuidas entre los cuatro integrantes.

Hipótesis de diseño

Elemento Hipótesis de diseño
Punto de sensibilidad Contrato del puerto IdentityVerificationProvider entre el servicio de Identidad y la implementación específica del proveedor KYC.
Hipótesis de diseño Si la integración de KYC se implementa mediante el patrón Puertos y Adaptadores, manteniendo una interfaz interna estable entre el dominio y los proveedores externos, entonces será posible sustituir un proveedor KYC sin modificar los componentes consumidores del dominio.
Historia de arquitectura asociada EC06 - Facilidad de modificación: cambio del proveedor KYC o de pagos por uno nuevo.
Nivel de incertidumbre Alto. La arquitectura establece interfaces y adaptadores para desacoplar los proveedores externos, pero debe comprobarse que el contrato diseñado realmente evita la propagación de cambios cuando el proveedor utiliza un contrato diferente.

Patrones de Arquitectura asociados al experimento

Patrón de Arquitectura asociado al experimento Descripción
Patrón 3: Puertos y Adaptadores Los servicios del dominio utilizan puertos internos que expresan las operaciones requeridas por Solventa. Los adaptadores implementan estos contratos y traducen entre el modelo interno y las particularidades de cada proveedor externo.

Tácticas de Arquitectura asociadas al experimento

Táctica de Arquitectura asociada al experimento Descripción
Hide information Las particularidades del proveedor KYC, como contratos, formatos, URL y mecanismos específicos de integración, permanecen ocultas dentro del adaptador y no son conocidas por el servicio consumidor.
Maintain existing interfaces El servicio de Identidad continúa utilizando el mismo puerto IdentityVerificationProvider aunque cambie la implementación encargada de comunicarse con el proveedor externo. Esto busca evitar que el cambio se propague hacia los consumidores.
Use an intermediary El adaptador funciona como intermediario entre el servicio de dominio y el proveedor KYC, traduciendo el contrato externo al contrato interno de Solventa y absorbiendo las diferencias entre proveedores.

Listado de componentes involucrados en el experimento

Microservicio / Componente Propósito y comportamiento esperado Tecnología asociada
Identidad, KYC y Consentimiento Solicitar la verificación de identidad mediante el puerto interno. Su implementación no debe cambiar al sustituir el proveedor KYC. Python + FastAPI / ECS Fargate
Adaptador KYC Implementar el puerto de verificación de identidad y traducir entre el modelo interno de Solventa y el contrato particular del proveedor externo. AWS Lambda
Proveedor KYC simulado A Representar el proveedor inicialmente utilizado durante el experimento. Mock/Stub
Proveedor KYC simulado B Representar un segundo proveedor con un contrato externo diferente para comprobar si el cambio permanece aislado en el adaptador. Mock/Stub

Listado de conectores involucrados en el experimento

Conector Comportamiento deseado en el experimento Tecnología asociada
Identidad - Puerto KYC Mantener un contrato estable independientemente del proveedor externo configurado. IdentityVerificationProvider
Puerto - Adaptador KYC Delegar la verificación hacia la implementación correspondiente sin exponer detalles del proveedor al dominio. Interfaz interna / implementación del adaptador
Adaptador - Proveedor KYC Traducir la solicitud y respuesta según el contrato particular de cada proveedor. HTTP/HTTPS
Pruebas - Servicio de Identidad Ejecutar el mismo conjunto de pruebas antes y después del reemplazo del proveedor para detectar propagación de cambios o regresiones. Pytest / GitHub Actions

Tecnología asociada con el experimento

Tecnología asociada con el experimento Justificación
Lenguajes de programación Python, lenguaje definido para los servicios backend y adaptadores de Solventa.
Plataforma de despliegue AWS ECS Fargate para los servicios de dominio y AWS Lambda para los adaptadores externos, según la vista de despliegue.
Bases de datos PostgreSQL.
Herramientas de análisis Pytest para verificar el comportamiento del servicio antes y después de sustituir el proveedor y GitHub Actions para ejecutar la regresión automatizada.
Librerías pytest para las pruebas de regresión, httpx para la comunicación HTTP con los proveedores KYC simulados y pytest-mock para simular las dependencias externas durante el experimento.
Frameworks de desarrollo FastAPI para los servicios backend. Los contratos de las APIs se documentan mediante OpenAPI.

Interpretación de resultados

Resultado obtenido Interpretación
El proveedor se sustituye modificando únicamente el adaptador y existen cero cambios en los consumidores La evidencia obtenida soporta la hipótesis de diseño y el criterio evaluado de EC06.
Es necesario modificar el servicio de Identidad u otro consumidor La hipótesis queda refutada porque el cambio del proveedor se propagó fuera del adaptador.
Es necesario modificar el puerto IdentityVerificationProvider El contrato interno presenta acoplamiento con las particularidades del proveedor y debe revisarse antes de considerar validada la hipótesis.
El cambio queda aislado en el adaptador, pero aparecen fallos en la regresión La localización estructural del cambio funciona, pero la sustitución no mantiene completamente el comportamiento esperado. Se requiere analizar los contratos y transformaciones involucrados.

Distribución de actividades por integrante

Integrante Tareas a realizar Esfuerzo estimado
Ana María Solano Definir y automatizar los casos que permitan comprobar que el consumidor mantiene el mismo comportamiento antes y después del cambio de proveedor. 6 h*
Juan Esteban Herrera Preparar el puerto IdentityVerificationProvider y el adaptador correspondiente al primer proveedor. 6 h*
Harold Virguez Preparar el segundo proveedor simulado y su adaptador manteniendo el contrato interno definido. 6 h*
Fernando Parra Ejecutar la regresión, revisar los componentes modificados y consolidar la evidencia del experimento. 6 h*
Total 24 h*

*Estimación inicial.

Resumen de experimentos

Experimento ASR Patrón principal Tácticas de arquitectura evaluadas
Latencia del perfilamiento EC02 Cache-Aside Maintain multiple copies of data or computations
Escalabilidad de cotización EC03 Redundancia Multi-AZ y Autoescalado Introduce concurrency; Maintain multiple copies of data or computations; Increase available resources
Cambio de proveedor KYC EC06 Puertos y Adaptadores Hide information; Maintain existing interfaces; Use an intermediary

Referencias Tácticas de Arquitectura

Software Architecture in Practice. 4th Edition. Len Bass, Paul Clements, Rick Kazman. SEI Series in Software Engineering. Adisson- Wesley. 2022. ISBN-13: 978-0-13-688609-9

⚠️ **GitHub.com Fallback** ⚠️