Semana 7 - JuanHerreraP/Proyecto-MISO-Solventa-Grupo-11 GitHub Wiki
1. Versión final del prototipo
Decisiones de diseño visual - Solventa: Style Tile - UX/UI
1.a Versión web
| HU | Relación con las pantallas en Figma |
|---|---|
| HU10 – Enriquecimiento del perfil de riesgo | 02 Consentimiento, 03 Perfil de riesgo |
| HU11 – Generación del perfil de riesgo y pricing | 03 Perfil de riesgo, 04 Cotización |
| HU12 – Generación y envío de la póliza | 06 Póliza emitida |
| HU13 – Procesamiento del recaudo inicial | 05 Pago y firma, 13 Pagos |
| HU14 – Firma electrónica del contrato | 05 Pago y firma |
| HU15 – Desembolso automatizado de indemnizaciones | 10 Estado de siniestro |
| HU17 – Renovación automática de pólizas | 11 Mis pólizas, 12 Gestionar póliza |
| HU18 – Gestión de cancelación de póliza | 11 Mis pólizas, 12 Gestionar póliza |
| HU19 – Registro, onboarding y autenticación | 00 Inicio de sesión, 01 Crear cuenta, 02 Consentimiento, 14 Perfil y preferencias |
| HU20 – Registro estructurado de siniestros | 09 Reportar siniestro, 10 Estado de siniestro |
| HU24 – Onboarding técnico de socios | 08 Portal de socios |
| HU25 – Historial de transacciones y movimientos | 07 Panel de inicio, 11 Mis pólizas, 13 Pagos |
1.b Versión Móvil
| HU | Relación con las pantallas en Figma |
|---|---|
| HU01 – Registro con verificación biométrica | 00 Bienvenida, 03 Crear cuenta, 04 Verificación de identidad, 05 Registro exitoso, 37 Datos personales |
| HU02 – Ingreso biométrico | 00 Bienvenida, 01 Ingreso biométrico, 02 Acceso con credenciales, 38 Seguridad y privacidad |
| HU03 – Cotizar un seguro | 07 Selección de ramo, 08 Datos de cotización, 09 Resultado de cotización |
| HU04 – Reportar siniestro con evidencias | 28 Reportar siniestro, 29 Evidencias, 30 Borrador offline, 31 Siniestro registrado, 32 Seguimiento |
| HU05 – Notificaciones push | 06 Inicio, 26 Notificaciones, 38 Seguridad y privacidad |
| HU06 – Buscar prestadores y solicitar asistencia | 33 Prestadores cercanos, 34 Detalle de prestador, 35 Asistencia activa, 36 Asistencia cancelada |
| HU07 – Billetera de pólizas | 06 Inicio, 16 Billetera digital, 18 Detalle de póliza, 19 Certificado digital, 20 Historial de póliza |
| HU08 – Billetera offline y sincronización | 06 Inicio, 17 Billetera offline, 38 Seguridad y privacidad |
| HU09 – Consultar detalle de póliza | 18 Detalle de póliza, 19 Certificado digital, 20 Historial de póliza |
| HU21 – Pagar prima pendiente | 21 Prima pendiente, 11 Medio de pago, 12 Pago aprobado, 13 Pago rechazado |
| HU22 – Renovar o cancelar póliza | 22 Renovar póliza, 23 Renovación exitosa, 24 Cancelar póliza, 25 Cancelación exitosa |
| HU23 – Aceptar cotización, pagar, firmar y emitir | 10 Resumen de compra, 11 Medio de pago, 12 Pago aprobado, 13 Pago rechazado, 14 Firma electrónica, 15 Póliza emitida |
| Transversal | 27 Perfil, 39 Idioma y moneda |
2. Resultados finales de experimentación
2.a Evidencias de la experimentación
- Resultados Experimento 1 - Latencia del perfilamiento mediante Cache-Aside
- Resultados Experimento 2 - Escalabilidad del servicio de cotización
- Resultados Experimento 3 - Facilidad de modificación mediante Puertos y Adaptadores
2.b Análisis de resultados
La estrategia de experimentación de Solventa permitió evaluar empíricamente la arquitectura frente a los atributos de calidad de latencia (EC02), escalabilidad (EC03) y facilidad de modificación (EC06) . Las pruebas demostraron que los patrones de diseño aplicados en los Experimentos 1 y 3 cumplieron con los escenarios de calidad previstos . Por el contrario, el Experimento 2 identificó limitaciones en el empaquetamiento inicial de los servicios, lo que motivó un ajuste en la topología de despliegue y en la integración de componentes
Experimento 1: Latencia del perfilamiento mediante Cache-Aside (EC02) Evaluó el uso de Amazon ElastiCache Redis para almacenar perfiles de riesgo y evitar llamadas síncronas repetidas a fuentes externas de Open Finance y Open Data . Los resultados en el escenario de Cache Hit confirmaron la hipótesis al mantener de forma consistente la latencia dentro del criterio EC02 (p95 ≤ 400 ms y p99 ≤ 800 ms) en todas las ejecuciones.
Experimento 2: Escalabilidad del servicio de cotización (EC03) Buscó validar si la infraestructura en AWS ECS Fargate soportaba picos de carga de 50.000 cotizaciones/minuto . La co-ubicación de múltiples microservicios dentro de una misma definición de tarea (Task Definition) generó cuellos de botella de procesamiento bajo alta concurrencia, impidiendo sostener el throughput y la latencia exigidos por el ASR. Ante este hallazgo, se rediseñó la arquitectura de despliegue para incorporar colas de mensajería (Amazon SQS) para gestionar el flujo asíncrono entre la cotización y el perfilamiento.
Experimento 3: Facilidad de modificación mediante Puertos y Adaptadores (EC06) Evaluó el aislamiento arquitectónico al sustituir el proveedor de verificación de identidad (KYC) . Se logró alternar entre dos proveedores distintos mediante la configuración de variables de entorno sin modificar el servicio consumidor ni la interfaz del puerto, superando con éxito el 100% de la suite de regresión y confirmando el cumplimiento de EC06.
3. Documento de arquitectura ajustado
Gran parte de la arquitectura definida durante la Semana 6 se mantiene vigente para la Semana 7. Únicamente la vista de despliegue refleja un cambio el cual corresponde a los hallazgos del experimento 2, principalmente debido a que no se cumplieron con las hipótesis esperadas obligando a este cambio en la arquitectura para cumplir con el ASR definido de picos de carga.
Este cambio corresponde a un trade-off que se realiza con el fin de evitar costos desorbitados debido a la gran cantidad de VCPUs que debe escalar el sistema para hacer frente a las 50.000 peticiones por minuto, lo que nos lleva a sacrificar la latencia durante estos picos de peticiones, pero asegurando la robustez del sistema evitando pérdidas de peticiones haciendo uso de colas de mensajería.
3.a Vista funcional
La vista funcional general y la vista funcional móvil incluyen los componentes principales de Solventa, sus responsabilidades, los conectores entre canales, BFF, servicios de dominio, adaptadores y proveedores externos, así como los flujos de control síncronos y asíncronos.
3.b Vista de despliegue
La vista de despliegue incluye la asignación de componentes y conectores a sus nodos de ejecución: canales, API Gateway, Application Load Balancer, ECS Fargate, SNS/SQS, Aurora PostgreSQL, ElastiCache Redis, AWS Lambda y zonas de disponibilidad.
3.c Vista de información
La vista de información incluye los modelos de datos, relaciones, estructuras y flujos principales entre clientes, consentimientos, perfiles de riesgo, cotizaciones, suscripciones, pólizas, pagos, siniestros, evidencias e indemnizaciones.
La estrategia de réplica está representada en la arquitectura mediante Aurora PostgreSQL Multi-AZ, mientras que Redis se utiliza como almacenamiento temporal para caché e idempotencia.
3.d Patrones de diseño detallado
Se mantienen los patrones detallados de la Semana 4 y su relación con los ASR del proyecto. Estos patrones continúan siendo pertinentes para las decisiones de seguridad, modificabilidad, disponibilidad, integridad, latencia y escalabilidad de Solventa.
- Patrón 1: API Gateway para centralizar el acceso
- Patrón 2: Backend for Frontend para web y Android
- Patrón 3: Puertos y Adaptadores
- Patrón 4: Offline-First con sincronización
- Patrón 5: Mensajería asíncrona con consumidor idempotente
- Patrón 6: Cache-Aside
- Patrón 7: Redundancia Multi-AZ y Autoescalado
Los modelos y patrones se conservarán bajo revisión durante las siguientes iteraciones, según la evidencia obtenida de los experimentos y del desarrollo del proyecto.