Maestría en Ingeniería de Software — MISW4501 Arquitectura de Software Caso de estudio: Solventa — plataforma insurtech

---

Título del experimento	Modelo de lectura de baja latencia para el estado de siniestro mediante CQRS con proyección materializada y caché
Propósito del experimento	Evaluar si las tácticas de latencia propuestas para la consulta de estado de siniestro —desacoplar el modelo de lectura del de escritura, materializar una proyección desnormalizada y servirla desde un almacén en memoria— permiten cumplir el ASR EC-LAT-11 (p95 ≤ 150 ms), y determinar cuál es el nivel mínimo de complejidad que lo satisface.
Resultados obtenidos	Resultado 1: la línea base ya cumple el ASR. La lectura directa sobre el modelo transaccional normalizado (brazo A, sin CQRS) alcanzó un p95 de 7,86 ms contra un umbral de 150 ms — 19× de margen. Los tres brazos cumplen: A 7,86 ms, B (proyección) 6,19 ms, C (proyección + caché) 6,72 ms, con 0 % de error en las 9 corridas contrabalanceadas. Resultado 2: el caché no aporta, cuesta. El orden observado es A > C > B (reproducible en las 3 repeticiones de cada brazo): C es 9 % más lento que B, no más rápido. Con el hit-rate real medido (7,6 % con TTL=30 s), la mayoría de las peticiones de C ejecutan el trabajo completo de B más la serialización y escritura a Redis. Subir el TTL a 300 s eleva el hit-rate a 32-33 % pero empeora el p95 (6,50 ms vs. 6,27 ms sin caché). Resultado 3: el dictamen resiste condiciones más adversas. Se repitió el brazo A con shared_buffers reducido 4× (256→64 MB) y el conjunto caliente dispersado físicamente en vez de contiguo: el p95 solo sube a 8,19 ms (+4,2 %), manteniendo 18× de margen. El CPU de Postgres casi se triplicó, confirmando que sí se forzó E/S real y no un resultado artificial del montaje. Resultado 4: no se encontró el punto de quiebre. Ni siquiera con un pico de 600 req/s (7,5× la carga del protocolo formal) ningún brazo se acercó al umbral: p95 de 2,87-3,46 ms, 0 % de error, 0 iteraciones descartadas.
Esfuerzo total invertido	Tiempo: 1,5 semanas — 60 horas Horas hombre: 15 horas/hombre (4 integrantes)

---

Punto de sensibilidad	Grado de separación del modelo de lectura. Es la decisión arquitectónica central: cuánta separación entre comando y consulta se requiere para satisfacer el ASR. Se varió en tres niveles —A lectura directa sobre el modelo normalizado (sin separación), B proyección materializada persistente, C proyección + caché en memoria— junto con dos puntos secundarios: la política de caché (TTL de 0/30/300 s) y la tasa de llegada de consultas (rampa de 10 a 80 req/s, extendida a un pico de 600 req/s).
Historia de arquitectura asociada	HA-08 — Modelo de lectura de baja latencia para el estado de siniestro · ASR EC-LAT-11 (Latencia, prioridad A,A)
Nivel de incertidumbre	Medio-Alto. El equipo tiene experiencia previa con CQRS, pero desconocía si la proyección por sí sola bastaba o si el caché era indispensable, cuánto lag introduce el proyector bajo carga concurrente, y cuál es el punto de quiebre de cada alternativa. El costo de equivocarse es alto: revertir CQRS una vez adoptado implica reescribir el camino de lectura y el proceso de evaluación completo.

---

1- Indique si la hipótesis de diseño pudo ser confirmada o no 2- En caso de que la hipótesis se haya confirmado, explique las decisiones de arquitectura que favorecieron el resultado 3- En caso de que los resultados del experimento no hayan sido favorables, explique por qué y cuáles cambios realizaría en el diseño

1. La hipótesis no se confirma — y esa es la información que el experimento aporta. HD-08 postulaba que la separación del modelo de lectura era necesaria para cumplir EC-LAT-11. El experimento demuestra cuantitativamente lo contrario: a 1.000.000 de siniestros y en el rango de carga ensayado, la línea base sin CQRS ya satisface el umbral con 19× de margen. La sub-hipótesis HD-08.1 (la lectura directa no alcanza el p95 objetivo) queda refutada; HD-08.2 (la proyección reduce el p95 ≥ 60 %) queda refutada en magnitud (la reducción real es 21 %); HD-08.3 (el caché aporta mejora adicional) queda refutada en la dirección contraria (C es 9 % peor que B). Solo HD-08.4 (lag de proyección ≤ 2 s) se acepta, con el lag medido por debajo de 50 ms.

Esto no es un experimento fallido: el propio diseño (Anexo B) anticipaba este desenlace —«si el brazo B ya cumple el umbral, el caché constituye complejidad no justificada y la recomendación debe ser la alternativa más simple que satisface el ASR»— y lo que se materializó fue una versión más extrema de ese escenario, donde ni siquiera B es necesario para la latencia.

2. Decisiones de arquitectura que explican el resultado. El estilo de microservicios ya adoptado en Solventa desfavorece la latencia por los saltos de red adicionales, y CQRS se había propuesto como contramedida deliberada a esa contrapartida. El experimento muestra que, al volumen actual, esa contramedida no hace falta: la táctica de reducir la demanda computacional que la proyección materializada implementa (trasladar los joins fuera del camino crítico) sí produce una mejora real y reproducible —B es 21 % más rápido que A—, pero opera sobre una latencia que ya estaba 19× por debajo del umbral. La táctica de mantener múltiples copias (el caché en memoria) resulta contraproducente con el patrón de acceso ensayado: introduce una escritura a Redis en cada fallo de caché que cuesta más de lo que ahorran los aciertos.

Hay una excepción importante, y es la que sí justifica CQRS: durante la corrida de alta carga, el brazo A impuso ~2,5× la carga de CPU sobre PostgreSQL frente a B y C. Esa proporción es la que competiría con las transacciones de negocio (creación de siniestros, actualización de hitos) por los mismos recursos del almacén transaccional. La justificación válida para separar el modelo de lectura no es la latencia, es el aislamiento de carga — un atributo que este experimento no midió directamente y que requeriría un experimento propio.

3. Cambios que se harían en el diseño. Dos caminos honestos, ninguno es «implementar B porque es más rápido»:

• Adoptar A como línea base y reconsiderar CQRS solo si el volumen real de producción, el patrón de acceso o el tráfico de escritura concurrente difieren sustancialmente de lo ensayado. Para que esta decisión sea falsable hace falta anclar EC-LAT-11 a una volumetría de negocio (siniestros activos × consultas por siniestro/día × factor de pico), cifra que hoy no existe en el escenario de calidad.
• Implementar B (proyección sin caché) justificándolo por aislamiento de carga, no por latencia, y descartar C: agrega Redis, invalidación y TTL a cambio de una degradación medible. Si se implementara C de todos modos, dos correcciones son obligatorias: escribir en caché de forma asíncrona (el costo está en el SET, no en la lectura fallida) y cerrar la ventana de carrera entre la invalidación del proyector y la escritura del brazo C, que hoy puede dejar datos obsoletos hasta que expire el TTL.

Límites de estas conclusiones. El montaje favorece estructuralmente al brazo A —dataset de 1M registros con el conjunto caliente enteramente cacheable, sin latencia de red entre componentes, siniestros con estructura fija de 5 hitos y 3 documentos— y el staleness que percibe el cliente nunca se midió (solo el lag interno del proyector), por lo que el segundo criterio de refutación del Anexo B no es evaluable con los datos recogidos. El dictamen debe leerse como «A cumple en estas condiciones», no como una garantía a cualquier escala.

---

1- Presente evidencias de los resultados obtenidos en el experimento.

Implementación y evidencia cruda: experiments/ha-08-lectura-siniestro/ — montaje Docker Compose completo (API con los tres brazos, proyector, simulador, almacenes, caché, broker y observabilidad), scripts de orquestación y carga.

Datos crudos auditables: results/raw/ — summary_*.json de k6, stats_*.csv de recursos por contenedor, lag_*.txt y cache_*.txt de cada una de las 20 corridas ejecutadas, versionados en el repositorio para que cada cifra de este informe sea recalculable sin reproducir las corridas. Consolidado en results/consolidado.csv.

Informe detallado: Informe de resultados HA-08 v2 — resultados por corrida, sensibilidad al TTL, sensibilidad a la carga, amenazas a la validez completas (Anexo D) y capturas del dashboard de Grafana por serie.

Bitácora técnica del proceso: experiments/ha-08-lectura-siniestro/INFORME.md — incluye la detección y corrección de un defecto de orquestación que invalidó una primera ejecución completa de 12 corridas, y el detalle de cada corrección aplicada tras tres rondas de revisión externa.

Diseño del experimento: Diseno_Experimento_HA-08.md · Guía técnica: Guia_Tecnica_HA-08.md