Razonamiento y patrones modelo de componentes S4 - JohannPaezU/MISW4501-MediSupply GitHub Wiki

Disponibilidad:

Táctica aplicada #1: Detección de fallas (Monitor)

Consiste en:

  • Un componente dedicado (Monitor) que recibe los estados y eventos operativos de los demás servicios.
  • No interviene en el negocio: solo observa y registra; su única función es visibilidad y alerta.

Razonamiento sobre las decisiones de arquitectura

  • Observabilidad centralizada: Concentrar en un único componente la recolección de estados reduce la dispersión de métricas y agiliza el diagnóstico.
  • No intrusivo: El Monitor consume sin acoplarse a los flujos; así no agrega latencia ni se convierte en cuello de botella.
  • Continuidad de información: Al llegarle los eventos por un canal común, se facilita reconstruir el contexto (qué falló, cuándo y en qué dominio) y acortar el tiempo de recuperación.
  • Gobernanza operativa: Un solo punto para generar alertas y tableros facilita acordar umbrales y reglas de notificación a operación.

Táctica aplicada #2: Múltiples copias de computación (manejo de recursos)

Consiste en:

  • Disponer de varias réplicas de la base de datos (primaria y secundarias) distribuidas en distintos nodos.
  • La base de datos primaria recibe las escrituras, mientras que las réplicas pueden asumir funciones de solo lectura o convertirse en primarias en caso de falla.

Razonamiento sobre las decisiones de arquitectura

  • Alta disponibilidad: Ante una caída de la base de datos principal, una réplica puede ser promovida a primaria, reduciendo el tiempo de inactividad.
  • Distribución de carga: Al direccionar las consultas de lectura hacia las réplicas, se reduce la presión sobre la instancia principal, mejorando el rendimiento global.
  • Escalabilidad horizontal: La adición de nuevas réplicas permite crecer en capacidad sin modificar la lógica de los servicios consumidores.

Seguridad:

Táctica aplicada #1: Autenticación (Autenticar actores)

Consiste en:

  • Los usuarios solicitan acceso al Authorizator, que emite un Authorization Token.
  • El API Gateway valida ese token antes de enrutar cualquier petición a los dominios internos.

Razonamiento sobre las decisiones de arquitectura

  • Control en el perímetro: Verificar identidad en el Gateway evita que tráfico no autenticado alcance servicios internos.
  • Separación de responsabilidades: Mantener el Authorizator independiente del API Gateway permite escalar, auditar, rotar claves y cambiar políticas sin tocar el enrutamiento.
  • Política uniforme: Un solo punto de validación garantiza reglas consistentes (expiración, scopes) para todo el ecosistema.

Táctica aplicada #2: Certificación (certificados digitales entre servicios)

Consiste en:

  • El API Gateway solicita/recibe certificados del Certificator.
  • Esos certificados habilitan confianza y cifrado en las comunicaciones internas.

Razonamiento sobre las decisiones de arquitectura

  • Confianza de servicio a servicio: Los certificados permiten autenticar componentes y evitar suplantación dentro de la red interna.
  • Ciclo de vida centralizado: Con un Certificator se estandariza emisión, renovación y revocación; menos riesgo operativo y menor complejidad en cada dominio.