📋 Hoja de trabajo

Hoja de trabajo con objetivos, restricciones y requisitos de calidad. Épicas e historias de usuario en la plataforma escogida (DevOps, Jira).

Objetivos

Objetivo 1

Criterio	Detalle del Objetivo
Objetivo de negocio	Alcanzar una cartera de 5 millones de pólizas activas
Descripción del objetivo	Lograr una base consolidada de 5 millones de pólizas activas mediante ventas directas y canales embebidos, soportando el alto volumen transaccional sin degradación de la experiencia de usuario.
Tiempo de cumplimiento	36 meses
Mejora esperada al negocio	Crecimiento exponencial en el Market Share, consolidando el modelo de negocio masivo con un alto volumen de ingresos por primas.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo	Afecta críticamente el Desempeño (Escalabilidad). se deben aplicar tácticas de manejo de recursos como "mantener múltiples copias de procesamiento" e "introducción de concurrencia". Esto obliga a usar el patrón de Microservicios para escalar independientemente el dominio de pólizas. Estas decisiones definirán la Vista de Concurrencia y la Vista de Despliegue para distribuir la carga en múltiples nodos.

Objetivo 2

Criterio	Detalle del Objetivo
Objetivo de negocio	Construir una red de más de 30 socios de distribución
Descripción del objetivo	Integrar a más de 30 aliados estratégicos (bancos, aerolíneas, e-commerce) exponiendo el catálogo y cotización a canales de terceros vía API de forma embebida.
Tiempo de cumplimiento	36 meses
Mejora esperada al negocio	Reducción del costo de adquisición de clientes (CAC) y diversificación de los canales de venta.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo	Impacta fuertemente la Facilidad de Integración, la Facilidad de Modificación y la Seguridad. Arquitectónicamente, exige un API Gateway para aislar las peticiones. Para facilitar la modificación, requerimos un "bajo acoplamiento" entre los componentes internos y los socios externos mediante el uso de interfaces (APIs). Además, requerirá aplicar tácticas de seguridad como la "autenticación" y "autorización" de cada socio mediante tokens o certificados.

Objetivo 3

Criterio	Detalle del Objetivo
Objetivo de negocio	Expandir la operación a México, Chile y Perú
Descripción del objetivo	Habilitar la plataforma core para operar en tres nuevos países, adaptando el sistema a las normativas locales de Open Finance y protección de datos, sin afectar el núcleo del sistema.
Tiempo de cumplimiento	36 meses
Mejora esperada al negocio	Diversificación del riesgo geográfico y aumento drástico del mercado total direccionable (TAM).
Cómo considera que pueda afectar la arquitectura del sistema este objetivo	Tensiona la Facilidad de Modificación. En entornos de alta demanda transaccional sabemos que cada cambio regulatorio no puede romper el core. Se sugiere lograr esto buscando "mantener una alta cohesión" en los componentes y reduciendo el acoplamiento. Se requiere una modularidad estricta (ej. Arquitectura Hexagonal) para aislar las adaptaciones de pasarelas de pago y entidades locales en adaptadores específicos sin tocar la lógica de negocio central.

Objetivo 4

Criterio	Detalle del Objetivo
Objetivo de negocio	Sostener un ratio combinado saludable soportado por suscripción basada en datos
Descripción del objetivo	Mantener la rentabilidad mediante la automatización de la evaluación de riesgos y fijación de precios en tiempo real, enriqueciendo el perfil del cliente con datos de Open Data y Open Finance.
Tiempo de cumplimiento	36 meses
Mejora esperada al negocio	Reducción significativa del fraude, control de la siniestralidad y optimización de márgenes operativos.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo	Afecta la Latencia. Al depender de fuentes externas impredecibles, es necesario aplicar tácticas como "ocultar los microservicios mediante el uso de una API Gateway" para enmascarar fallas. Para el procesamiento de datos asíncrono y la trazabilidad de decisiones actuariales, se sugiere utilizar una Arquitectura Orientada a Eventos (Event Sourcing), aislando las consultas complejas de los comandos de suscripción, aplicando el patrón CQRS para no bloquear los hilos principales.

Restricciones de negocio

Restricción de Negocio 1: Greenfield (sin sistemas heredados)

Restricciones de negocio
Descripción de la restricción	Solventa nace en 2026 sin sistemas heredados. No existe un core asegurador, un modelo de datos previo ni integraciones internas que reutilizar. El diseño parte desde cero.
Usuario que expresa esta restricción	CEO / Junta directiva, CTO / Arquitectura.
Justificación para esta restricción	El caso impone un modelo fintech greenfield. Quedan cerradas las estrategias brownfield (reuso de un core existente, strangler sobre un monolito legado o migración incremental desde un sistema anterior).
Cómo considera que pueda afectar la arquitectura del sistema esta restricción	Obliga a elegir y justificar estilo, persistencia y fronteras sin anclarse a un sistema previo. Toda la complejidad operable debe caber en el equipo actual; no se hereda operación, datos históricos ni conocimiento de un core antiguo.

Restricción de Negocio 2: Equipo reducido y evolución organizacional

Restricciones de negocio
Descripción de la restricción	El equipo es reducido (4 personas en el ciclo de arquitectura) y el sistema debe poder crecer con el negocio. La complejidad organizacional aumenta con la escala, pero no está disponible el día uno.
Usuario que expresa esta restricción	CEO / Junta directiva, CTO / Arquitectura, Equipos de desarrollo.
Justificación para esta restricción	Un diseño que exija muchos equipos, un área SRE dedicada o un proceso de release pesado no es operable al inicio. La arquitectura debe ser evolutiva, no presuponer la organización de los 36 meses.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción	Favorece una modularidad que permita crecer el equipo después, sin exigir esa organización al arranque. Limita el número de desplegables y la carga operativa que el equipo de 4 personas puede sostener.

Restricciones de tecnología

Restricción de Tecnología 1: Infraestructura exclusiva en nube pública


Descripción de la restricción	El sistema se diseña, construye y ejecuta en una plataforma de nube pública (AWS, GCP o Azure). Queda prohibida la infraestructura física local (on-premises) y los servidores dedicados tradicionales.
Usuario que expresa esta restricción	CEO / Junta directiva, CTO / Arquitectura.
Justificación para esta restricción	El caso impone nube primero como decisión ya tomada. Cierra el espacio de diseño on-premises. La elasticidad, el multi-zona y el autoescalado no forman parte de esta restricción: son requisitos de escalabilidad.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción	Impide dimensionar un data center propio o un core en servidores dedicados. El proveedor de nube queda como premisa de despliegue; las metas medibles de capacidad se especifican en los escenarios de calidad, no aquí.

Restricción de Tecnología 2: Stack de implementación ya decidido


Descripción de la restricción	El dominio se implementa en Python. El cliente web se implementa en Angular. El cliente móvil se implementa en Android / Kotlin. No se introduce un segundo runtime de negocio ni se unifica web y móvil en un único cliente híbrido.
Usuario que expresa esta restricción	CTO / Arquitectura, Equipos de desarrollo.
Justificación para esta restricción	El caso no prescribe estilo arquitectónico, pero el equipo ya fijó el stack de entrega. Esa decisión cierra alternativas (otro backend, solo web responsiva, o un único cliente híbrido) y no es un atributo de calidad.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción	Acota librerías, empaquetado y pipeline a ese stack. Cómo se exponen las APIs a cada canal (API única vs. BFF) y las capacidades de cámara, biometría u offline son requisitos funcionales o de integración, no esta restricción.

Requisitos de calidad

Cada escenario usa un entorno y una sola medida de respuesta. La latencia no se mezcla con la escalabilidad. La única excepción es la escalabilidad, que admite volumen y ventana temporal en la misma medida.

6.1 Latencia

Requisitos tal como los enuncia el caso (PDF §6.1), con las dos historias de arquitectura que los desarrollan.

Requisito	Estímulo	Respuesta medible	Historias
Cotización embebida	Socio pide cotización en horario pico.	p95 ≤ 250 ms; p99 ≤ 500 ms extremo a extremo.	HA-01 · HA-02
Perfilamiento en línea (vida hipotecario)	Se dispara el perfilamiento con Open Data / Open Finance.	p95 ≤ 400 ms; p99 ≤ 800 ms.	HA-03 · HA-04
Suscripción y emisión automática	El cliente acepta la oferta.	Decisión + emisión p95 ≤ 1,5 s; p99 ≤ 3 s.	HA-09 · HA-10
Presupuesto por dependencia externa	Cada llamada a un tercero (KYC, datos, pago).	≤ 120 ms por dependencia; timeout duro a 700 ms.	HA-05 · HA-06
Dependencia degradada	Un proveedor supera 700 ms o falla.	Degradar con caché o valor por defecto sin exceder el presupuesto del journey.	HA-07 · HA-08
Consulta de póliza y estado de siniestro	Cliente o socio consulta el estado.	p95 ≤ 150 ms; p99 ≤ 300 ms.	HA-11 · HA-12

Cada requisito se descompone en dos historias porque el enunciado mezcla dos medidas (p95 y p99) o dos ambientes (operación normal y horario pico), y cada historia debe tener una sola medida y un solo ambiente.

6.2 Escalabilidad

Requisito	Estímulo	Respuesta medible	Historias
Campaña masiva de socio	Un socio lanza una promoción; el tráfico crece 100×.	Escalar de 500 a 50.000 cotizaciones/min conservando el p95 (autoescalado ≤ 60 s).	HA-13 · HA-14
Originación hipotecaria a fin de mes	Pico de cierres de crédito de varios bancos aliados.	≥ 20.000 perfilamientos + ofertas/hora sin degradar el online.	HA-19 · HA-20
Evento paramétrico masivo	Un evento climático dispara pólizas paramétricas.	Absorber ≥ 1.000.000 de eventos en 10 min con contrapresión y sin pérdida.	HA-15 · HA-16
Reprocesamiento de perfiles (batch)	Se recalculan perfiles con nuevas fuentes de Open Data.	Reprocesar ≥ 10 M de perfiles en < 2 h sin afectar la latencia del tráfico en línea.	HA-21 · HA-22
Crecimiento del ecosistema de socios	Se pasa de 5 a 50 socios de distribución.	Alta de socios sin degradación y con aislamiento de carga por socio.	HA-17 · HA-18
Expansión a nuevo país	Se habilita un mercado nuevo.	Escalar por dominio y región sin reescribir el núcleo; onboarding de país en ≤ 4 semanas.	HA-23 · HA-24

La escalabilidad es el único atributo que admite más de una unidad en la misma medida, por lo que sus historias expresan el patrón completo de carga nominal, carga máxima y ventana de sostenimiento.

Backlog de arquitectura

Historias de arquitectura según la plantilla del curso:

Como [Fuente], cuando [Estímulo], dado que el sistema está en [Ambiente], quiero [Respuesta] para [Beneficio]. Esto debe suceder [Medida de la respuesta].

Una fuente, un estímulo, un ambiente y una medida por historia. La única excepción es la escalabilidad, que admite volumen y ventana temporal. El bloque Decide es la hipótesis de diseño, no el requisito.

Núcleo — latencia y escalabilidad (PDF §6.1 y §6.2). 12 requisitos, dos historias cada uno: HA-01/HA-02, HA-03/HA-04, HA-05/HA-06, HA-07/HA-08, HA-09/HA-10, HA-11/HA-12, HA-13/HA-14, HA-15/HA-16, HA-17/HA-18, HA-19/HA-20, HA-21/HA-22, HA-23/HA-24.

Fuera de este backlog. HA-18, HA-19 y HA-21 a HA-25 son historias de canal (proyecto SOLV). HA-34 a HA-43 son tácticas (hexagonal, EKS, CQRS, Kafka, BFF) y viven en Decide / spikes.

Índice de historias

ID	Historia	Eje	Ambiente	Medida
HA-01	Cotización embebida	Latencia	Operación normal	p95 ≤ 250 ms
HA-02	Cotización embebida en pico	Latencia	Horario pico	p99 ≤ 500 ms
HA-03	Perfilamiento en línea	Latencia	Operación normal	p95 ≤ 400 ms
HA-04	Perfilamiento en pico de originación	Latencia	Pico de fin de mes	p99 ≤ 800 ms
HA-05	Presupuesto por dependencia	Latencia	Operación normal	p95 ≤ 120 ms
HA-06	Corte duro ante dependencia lenta	Latencia	Proveedor lento	Timeout 700 ms · 100%
HA-07	Cotización con fuente degradada	Latencia	Operación degradada	p95 ≤ 250 ms
HA-08	Degradación sostenida	Latencia	Degradación sostenida	100% con respaldo
HA-09	Suscripción y emisión	Latencia	Operación normal	p95 ≤ 1,5 s
HA-10	Suscripción y emisión en pico	Latencia	Horario pico	p99 ≤ 3 s
HA-11	Consulta desde canal propio	Latencia	Operación normal	p95 ≤ 150 ms
HA-12	Consulta desde canal de socios	Latencia	Horario pico	p99 ≤ 300 ms
HA-13	Campaña masiva de socio	Escalabilidad	Carga transitoria alta	500 → 50.000 cot/min · 30 min
HA-14	Aprovisionamiento de capacidad	Escalabilidad	Rampa de carga	≤ 60 s
HA-15	Evento paramétrico masivo	Escalabilidad	Evento masivo	≥ 1.000.000 / 10 min
HA-16	Drenado de la cola	Escalabilidad	Recuperación posterior	100% exactamente una vez
HA-17	Ecosistema de socios	Escalabilidad	Ecosistema completo	50 socios con cuota
HA-18	Contención por cuota	Escalabilidad	Múltiples socios activos	100% dentro de cuota
HA-19	Originación de fin de mes	Escalabilidad	Carga alta programada	≥ 20.000/h · 4 h
HA-20	Aislamiento del online en el cierre	Escalabilidad	Carga alta programada	p95 ≤ 250 ms
HA-21	Reprocesamiento masivo	Escalabilidad	Lote fuera de pico	≥ 10 M / < 2 h
HA-22	Aislamiento del online en el lote	Escalabilidad	Lote concurrente	p95 ≤ 250 ms
HA-23	Escalado por región	Escalabilidad	Dos regiones activas	500 cot/min · p95 conservado
HA-24	Onboarding del país	Escalabilidad / Modificación	Expansión planificada	≤ 4 semanas

Historias de arquitectura

HA-01 · Cotización embebida en operación normal

Como socio de distribución, cuando solicito una cotización vía API, dado que el sistema está en operación normal a carga nominal, quiero recibir el precio en firme para mostrarlo dentro de mi propio recorrido de compra. Esto debe suceder en p95 ≤ 250 ms extremo a extremo.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Solicitud de cotización vía API
Artefacto	Orquestador de cotización y motor de rating
Ambiente	Operación normal a carga nominal
Respuesta	Se devuelve precio en firme
Medida	p95 ≤ 250 ms extremo a extremo

Decide: si el rating se ejecuta síncrono en línea o sobre valores precalculados; qué se cachea y con qué frescura; cuántos saltos de red admite el recorrido.

HA-02 · Cotización embebida en horario pico

Como socio de distribución, cuando solicito una cotización vía API, dado que el sistema está en horario pico con carga máxima sostenida, quiero recibir el precio en firme para sostener la conversión también en la hora de mayor demanda. Esto debe suceder en p99 ≤ 500 ms extremo a extremo.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Solicitud de cotización vía API
Artefacto	Orquestador de cotización y motor de rating
Ambiente	Horario pico con carga máxima sostenida
Respuesta	Se devuelve precio en firme
Medida	p99 ≤ 500 ms extremo a extremo

Decide: cuánta capacidad caliente se sostiene para acotar la cola larga; si la degradación selectiva se activa antes de romper el p99; dónde se ubica la cola de admisión.

HA-03 · Perfilamiento en línea en operación normal

Como cliente en originación de crédito, cuando otorgo el consentimiento y se dispara el perfilamiento con Open Data / Open Finance, dado que el sistema está en operación normal, quiero un perfil de riesgo con precio personalizado para seguir dentro del mismo flujo del crédito. Esto debe suceder en p95 ≤ 400 ms.

Parte	Contenido
Fuente	Cliente en originación de crédito
Estímulo	Se dispara el perfilamiento con consentimiento vigente
Artefacto	Motor de perfilamiento y capa de integración externa
Ambiente	Operación normal
Respuesta	Perfil de riesgo y precio personalizado
Medida	p95 ≤ 400 ms

Decide: paralelización de llamadas salientes; materialización previa de señales; particionamiento del cálculo entre línea y lote.

HA-04 · Perfilamiento en línea en pico de originación

Como cliente en originación de crédito, cuando otorgo el consentimiento y se dispara el perfilamiento con Open Data / Open Finance, dado que el sistema está en el pico de originación hipotecaria de fin de mes, quiero un perfil de riesgo con precio personalizado para cerrar mi crédito sin salir del flujo aunque sea fin de mes. Esto debe suceder en p99 ≤ 800 ms.

Parte	Contenido
Fuente	Cliente en originación de crédito
Estímulo	Se dispara el perfilamiento con consentimiento vigente
Artefacto	Motor de perfilamiento y capa de integración externa
Ambiente	Pico de originación hipotecaria de fin de mes
Respuesta	Perfil de riesgo y precio personalizado
Medida	p99 ≤ 800 ms

Decide: si el perfilamiento en línea y el lote de originación comparten pool de cómputo; prioridad de eventos entre canal en línea y canal bancario.

HA-05 · Presupuesto de latencia por dependencia

Como orquestador del journey de cotización, cuando invoco una dependencia externa de KYC, datos o pago, dado que el sistema está en operación normal, quiero obtener su respuesta dentro del presupuesto asignado para que ninguna dependencia consuma el presupuesto del recorrido completo. Esto debe suceder en p95 ≤ 120 ms por dependencia.

Parte	Contenido
Fuente	Orquestador del journey de cotización
Estímulo	Llamada saliente a un tercero
Artefacto	Adaptador de integración externa
Ambiente	Operación normal
Respuesta	Se obtiene la respuesta del tercero dentro del presupuesto
Medida	p95 ≤ 120 ms por dependencia

Decide: ubicación del control de timeout (adaptador, gateway o malla de servicios); política de reintentos y su costo en el presupuesto total.

HA-06 · Corte duro ante dependencia lenta

Como orquestador del journey de cotización, cuando una dependencia externa excede su presupuesto de latencia, dado que el sistema está operando con un proveedor externo lento, quiero cortar la espera y recuperar el control para aplicar el valor de respaldo dentro del presupuesto del recorrido. Esto debe suceder con timeout duro aplicado a los 700 ms en el 100% de las llamadas.

Parte	Contenido
Fuente	Orquestador del journey de cotización
Estímulo	La llamada saliente excede el presupuesto asignado
Artefacto	Adaptador de integración externa con temporizador
Ambiente	Operación con proveedor externo lento
Respuesta	Se corta la espera y se devuelve el control al orquestador
Medida	Timeout duro aplicado a los 700 ms en el 100% de las llamadas

Decide: timeout por dependencia frente a timeout global del recorrido; liberación del hilo y coste de la conexión abandonada.

HA-07 · Cotización con fuente externa degradada

Como socio de distribución, cuando solicito una cotización, dado que el sistema está en operación degradada porque un proveedor de Open Finance no responde dentro de su presupuesto, quiero recibir el precio calculado con el perfil en caché o el valor por defecto, marcado como decisión degradada, para no perder la venta. Esto debe suceder en p95 ≤ 250 ms del journey de cotización.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Solicitud de cotización
Artefacto	Adaptador de integración y caché de perfil
Ambiente	Operación degradada por dependencia externa
Respuesta	Cotización resuelta con caché o valor por defecto, marcada como decisión degradada
Medida	p95 ≤ 250 ms del journey de cotización

Decide: circuit breakers y su umbral de apertura; política de caché y frescura aceptable; qué valores por defecto son actuarialmente admisibles.

HA-08 · Degradación sostenida de la fuente externa

Como socio de distribución, cuando solicito cotizaciones de forma continua, dado que el sistema está en operación degradada sostenida porque un proveedor lleva más de 5 minutos sin responder, quiero que todas mis cotizaciones se resuelvan con el valor de respaldo para mantener el canal vendiendo durante toda la caída. Esto debe suceder en el 100% de las cotizaciones del periodo degradado.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Solicitud continua de cotizaciones
Artefacto	Cortacircuitos del adaptador de integración
Ambiente	Operación degradada sostenida
Respuesta	El cortacircuitos permanece abierto y todas las cotizaciones se resuelven con el valor de respaldo
Medida	100% de las cotizaciones resueltas con valor de respaldo

Decide: umbral y ventana de apertura del cortacircuitos; estrategia de sondeo para el cierre; cuánto tiempo es actuarialmente tolerable cotizar con respaldo.

HA-09 · Suscripción y emisión en operación normal

Como cliente, cuando acepto la oferta que se me presenta, dado que el sistema está en operación normal, quiero la decisión de suscripción y la póliza emitida para quedar cubierto dentro del mismo flujo. Esto debe suceder en p95 ≤ 1,5 s desde la aceptación hasta la póliza emitida.

Parte	Contenido
Fuente	Cliente
Estímulo	Acepta la oferta
Artefacto	Componente de suscripción, cobro y emisión
Ambiente	Operación normal
Respuesta	Decisión de suscripción, cobro de la prima y póliza emitida
Medida	p95 ≤ 1,5 s desde la aceptación hasta la póliza emitida

Decide: qué debe ser síncrono (decisión y emisión) frente a lo que puede diferirse (documentos, notificación); presupuesto de las dependencias de firma y pago dentro de los 1,5 s.

HA-10 · Suscripción y emisión en horario pico

Como cliente, cuando acepto la oferta que se me presenta, dado que el sistema está en horario pico con carga máxima sostenida, quiero la decisión de suscripción y la póliza emitida para quedar cubierto sin percibir espera aunque sea la hora de mayor demanda. Esto debe suceder en p99 ≤ 3 s desde la aceptación hasta la póliza emitida.

Parte	Contenido
Fuente	Cliente
Estímulo	Acepta la oferta
Artefacto	Componente de suscripción, cobro y emisión
Ambiente	Horario pico con carga máxima sostenida
Respuesta	Decisión de suscripción, cobro de la prima y póliza emitida
Medida	p99 ≤ 3 s desde la aceptación hasta la póliza emitida

Decide: qué parte del flujo admite encolamiento bajo pico sin romper la promesa comercial; idempotencia del cobro ante reintento del cliente.

HA-11 · Consulta de estado desde el canal propio

Como cliente asegurado, cuando consulto el estado de mi póliza o de mi siniestro desde el cliente web o móvil, dado que el sistema está en operación normal, quiero ver el estado vigente para resolver mi duda sin recurrir al canal telefónico. Esto debe suceder en p95 ≤ 150 ms.

Parte	Contenido
Fuente	Cliente asegurado
Estímulo	Consulta el estado desde el cliente web o móvil
Artefacto	Servicios de consulta de póliza y siniestro
Ambiente	Operación normal
Respuesta	Se devuelve el estado vigente
Medida	p95 ≤ 150 ms

Decide: separación de modelos de lectura y escritura; frescura aceptable de la vista de consulta.

HA-12 · Consulta de estado desde el canal de socios

Como socio de distribución, cuando consulto el estado de una póliza a través de la API, dado que el sistema está en horario pico, quiero recibir el estado vigente para resolverlo dentro de mi propia interfaz de atención. Esto debe suceder en p99 ≤ 300 ms.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Consulta el estado de una póliza vía API
Artefacto	Servicios de consulta y gateway de APIs de socios
Ambiente	Horario pico
Respuesta	Se devuelve el estado vigente de la póliza consultada
Medida	p99 ≤ 300 ms

Decide: si el canal de socios comparte el modelo de lectura del canal propio o tiene su propia proyección; cuota de lectura por socio.

HA-13 · Absorción de pico por campaña de socio

Como socio de distribución, cuando lanzo una promoción y el tráfico de cotización crece 100×, dado que el sistema está en carga transitoria alta, quiero que se sostenga el volumen completo de cotizaciones para convertir la campaña en ventas. Esto debe suceder operando con normalidad a 500 cotizaciones/min y escalando hasta 50.000 cotizaciones/min durante 30 minutos consecutivos.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	El tráfico de cotización crece 100× por una promoción
Artefacto	Servicio de cotización y su infraestructura de cómputo elástica
Ambiente	Carga transitoria alta
Respuesta	El sistema sostiene el volumen completo de cotización
Medida	500 cotizaciones/min nominales, escalando a 50.000 cotizaciones/min durante 30 min consecutivos

Decide: qué componentes escalan de forma independiente; disparadores y ventana del autoescalado; capacidad mínima caliente frente al costo de infraestructura ociosa.

HA-14 · Aprovisionamiento de capacidad durante la campaña

Como controlador de autoescalado, cuando el caudal de cotizaciones supera el umbral configurado, dado que el sistema está en la rampa de carga inicial de la campaña, quiero incorporar las réplicas adicionales al balanceo para absorber el crecimiento antes de que la cola se acumule. Esto debe suceder con la capacidad ampliada disponible en ≤ 60 s desde el disparo.

Parte	Contenido
Fuente	Controlador de autoescalado
Estímulo	El caudal de cotizaciones supera el umbral de escalado
Artefacto	Controlador de autoescalado del servicio de cotización
Ambiente	Rampa de carga al inicio de la campaña
Respuesta	Se aprovisionan las réplicas adicionales y se incorporan al balanceo
Medida	Capacidad ampliada disponible ≤ 60 s desde el disparo

Decide: métrica que dispara el escalado (CPU, cola, latencia observada); tiempo de arranque en frío del contenedor; capacidad de reserva precalentada.

HA-15 · Ingesta masiva de eventos paramétricos

Como fuente de telemetría climática, cuando emito la ráfaga de eventos que dispara pólizas paramétricas, dado que el sistema está en un evento masivo simultáneo, quiero que los eventos se absorban con contrapresión para que cada asegurado entre al pago automático. Esto debe suceder absorbiendo ≥ 1.000.000 de eventos en 10 minutos.

Parte	Contenido
Fuente	Fuente de telemetría climática
Estímulo	Ráfaga de eventos que dispara pólizas paramétricas
Artefacto	Canal de eventos y su almacenamiento de rezago
Ambiente	Evento masivo simultáneo
Respuesta	Los eventos se ingieren y persisten aplicando contrapresión
Medida	≥ 1.000.000 de eventos absorbidos en 10 min

Decide: mensajería asíncrona y garantías de entrega; particionamiento del flujo; idempotencia en el consumo y manejo de duplicados.

HA-16 · Drenado de la cola tras el evento masivo

Como canal de eventos, cuando entrego el rezago acumulado durante el pico, dado que el sistema está en recuperación posterior al evento masivo, quiero que cada evento se procese y dispare su pago automático una sola vez para que cada asegurado reciba su indemnización íntegra. Esto debe suceder con el 100% de los eventos encolados procesados exactamente una vez.

Parte	Contenido
Fuente	Canal de eventos
Estímulo	Entrega del rezago acumulado durante el pico
Artefacto	Procesador de siniestros paramétricos
Ambiente	Recuperación posterior al evento masivo
Respuesta	Se procesa la totalidad de los eventos encolados y se ejecutan los pagos automáticos
Medida	100% de los eventos encolados procesados exactamente una vez

Decide: clave de idempotencia del pago; almacenamiento del rezago y su retención; paralelismo del consumidor frente al orden de los eventos.

HA-17 · Atención concurrente del ecosistema de socios

Como socio de distribución, cuando consumo la API junto a los demás socios activos, dado que el sistema está en operación normal con el ecosistema completo, quiero que mi cuota se atienda íntegra para sostener mi propio canal de venta. Esto debe suceder con 50 socios concurrentes atendidos, cada uno dentro de su cuota.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Consumo concurrente de la API junto a los demás socios
Artefacto	Gateway de APIs de socios
Ambiente	Operación normal con el ecosistema completo
Respuesta	Cada socio recibe la atención íntegra de su cuota
Medida	50 socios concurrentes atendidos con su cuota propia

Decide: ubicación del control de cuotas; granularidad del aislamiento (por socio, por plan, por recurso).

HA-18 · Contención del socio que excede su cuota

Como socio de distribución, cuando consumo por encima de la cuota que tengo asignada, dado que el sistema está en operación con múltiples socios activos, quiero que el exceso se contenga dentro de mi propia cuota para que el resto del ecosistema conserve su capacidad íntegra. Esto debe suceder con la cuota por socio respetada en el 100% de las peticiones.

Parte	Contenido
Fuente	Socio de distribución
Estímulo	Consumo por encima de la cuota asignada
Artefacto	Gateway de APIs de socios con control de cuotas
Ambiente	Operación con múltiples socios activos
Respuesta	El exceso se contiene dentro de la cuota del socio emisor y el resto conserva su servicio
Medida	Cuota por socio respetada en el 100% de las peticiones

Decide: política ante exceso (rechazo, encolado o degradación); ventana de medición de la cuota; señalización del límite al socio.

HA-19 · Caudal de perfilamiento en el cierre de mes

Como banco aliado, cuando concentro los cierres de crédito en la ventana de fin de mes, dado que el sistema está en carga alta programada de fin de mes, quiero que se generen los perfilamientos con su oferta de vida hipotecario para no perder la originación. Esto debe suceder procesando ≥ 20.000 perfilamientos con oferta por hora, sostenidos durante 4 horas consecutivas.

Parte	Contenido
Fuente	Banco aliado
Estímulo	Concentración de cierres de crédito en la ventana de fin de mes
Artefacto	Motor de perfilamiento y su capacidad de cómputo
Ambiente	Carga alta programada de fin de mes
Respuesta	Se generan los perfilamientos y las ofertas de vida hipotecario
Medida	≥ 20.000 perfilamientos con oferta/hora sostenidos durante 4 h consecutivas

Decide: aislamiento de recursos entre carga en línea y por lotes; encolamiento y priorización.

HA-20 · Aislamiento del tráfico en línea durante el cierre

Como cliente del canal en línea, cuando cotizo mientras corre el pico de originación hipotecaria, dado que el sistema está en carga alta programada de fin de mes, quiero recibir mi cotización con el mismo desempeño de siempre para completar mi compra sin espera adicional. Esto debe suceder en p95 ≤ 250 ms durante toda la ventana del pico.

Parte	Contenido
Fuente	Cliente del canal en línea
Estímulo	Solicitud de cotización durante el pico de originación
Artefacto	Servicio de cotización en línea
Ambiente	Carga alta programada de fin de mes
Respuesta	Se atiende el tráfico en línea con el desempeño de la operación normal
Medida	p95 de cotización ≤ 250 ms durante toda la ventana del pico

Decide: separación física o lógica de pools entre canal bancario y canal en línea; prioridad de eventos entre ambos.

HA-21 · Ventana de reprocesamiento masivo

Como área de riesgo, cuando ordeno el recálculo de perfiles con las nuevas fuentes de Open Data, dado que el sistema está en ejecución programada fuera de la ventana pico, quiero que se reprocese la cartera completa para mantener la tarificación vigente. Esto debe suceder reprocesando ≥ 10 M de perfiles en menos de 2 horas.

Parte	Contenido
Fuente	Área de riesgo
Estímulo	Orden de recálculo de perfiles con nuevas fuentes
Artefacto	Pipeline de procesamiento por lotes
Ambiente	Ejecución programada fuera de la ventana pico
Respuesta	Se reprocesa la cartera completa de perfiles
Medida	≥ 10 M de perfiles en < 2 h

Decide: separación física de la carga por lotes; materialización de perfiles frente a cálculo bajo demanda.

HA-22 · Aislamiento del tráfico en línea durante el lote

Como cliente del canal en línea, cuando cotizo mientras corre el lote de reprocesamiento, dado que el sistema está ejecutando lote y tráfico en línea de forma concurrente, quiero recibir mi cotización con el desempeño de la operación normal para no percibir el proceso de fondo. Esto debe suceder en p95 ≤ 250 ms durante toda la ejecución del lote.

Parte	Contenido
Fuente	Cliente del canal en línea
Estímulo	Solicitud de cotización durante la ejecución del lote
Artefacto	Servicios en línea de cotización y perfilamiento
Ambiente	Ejecución concurrente de lote y tráfico en línea
Respuesta	Se atiende el tráfico en línea con el desempeño de la operación normal
Medida	p95 de cotización ≤ 250 ms durante toda la ejecución del lote

Decide: aislamiento de los almacenes de lectura entre lote y línea; contención del ancho de banda del pipeline.

HA-23 · Escalado por región del nuevo mercado

Como cliente de un mercado nuevo, cuando cotizo en la región recién habilitada, dado que el sistema está en operación normal con dos regiones activas, quiero recibir mi cotización con el desempeño de la región original para tener la misma experiencia desde el primer día. Esto debe suceder sosteniendo 500 cotizaciones/min en la región nueva conservando el p95 ≤ 250 ms de la región existente.

Parte	Contenido
Fuente	Cliente de un mercado nuevo
Estímulo	Solicitud de cotización en la región recién habilitada
Artefacto	Despliegue por región y núcleo de dominio compartido
Ambiente	Operación normal con dos regiones activas
Respuesta	La región nueva atiende su carga y la región existente conserva su desempeño
Medida	500 cotizaciones/min en la región nueva, con p95 ≤ 250 ms conservado en la región existente

Decide: qué es específico de país (regulación, moneda, proveedores, ramos) y qué es común; residencia de datos por jurisdicción; si las regiones comparten plano de control.

HA-24 · Onboarding del nuevo país

Como negocio de Solventa, cuando apruebo la habilitación de un mercado nuevo, dado que el sistema está en expansión regional planificada, quiero el país operativo con configuración local acotada para abrir México, Chile o Perú sin reescribir el núcleo. Esto debe suceder con el onboarding de país completado en ≤ 4 semanas calendario.

Parte	Contenido
Fuente	Negocio / expansión internacional
Estímulo	Aprobación de la habilitación de un mercado nuevo
Artefacto	Plataforma completa y su configuración por país
Ambiente	Expansión regional planificada
Respuesta	El país queda operativo con configuración y componentes locales acotados
Medida	Onboarding de país en ≤ 4 semanas calendario

Decide: qué queda parametrizado frente a qué exige código nuevo; automatización del aprovisionamiento regional.