Vista de Concurrencia

Modelo

El modelo presentado solo representa la vista de concurrencia y los elementos necesarios para entender las tacticas y los tradeoff seleccionados para los ASR escogidos, los modelos mas generales se encuentran en la seccion de Vision de Arquitectura

Escenario de Concurrencia

Vista General del Proceso

Enlace Imagen Ampliada

Vista de Concurrencia

Enlace Imagen Ampliada

Estilo Utilizado

En esta vista se puede observar el uso del estilo de arquitectura basada en microservicios donde se identifican los principales microservicios que son requeridos para la implementacion del MVP, en esta Vista podemos identificar tactica de replicación donde haremos uso de diferentes regiones que son ofrecidas por nuestro cloud provider seleccionado con lo cual mantendremos una alata disponibilidad de la aplicacion.

Con la utilización del estilo de microservicios esperamos favorecer algunos atributos de calidad como latencia, escalabilidad, facilidad de modificación.

Tácticas utilizadas

• Táctica de Introducir concurrencia que permita ejecutar varios procesos en paralelo lo que permita mantener estable la plataforma ante aumento de trafico temporal.

• Táctica de Incrementar recursos permitiedo el escalamiento horizontal para crear nuecos recursos que pueda favorecer ejecutar varios procesos en paralelo mejorando el (Desempeño).

• Táctica de Replicación con la cual podemos tener difententes instanacias Pods de nuestro microservicio desplegado en zonas geograficas diferentes o Regiones que nos proveea el proveedor cloud seleccionado

Patrones Utilizados

• Patron equilibrador de carga que permitira realizar una división de las peticiones entre los diferentes recursos o instancias disponibles para cada servicio envian la peticion a un unico nodo de ejecucion, adicional tambien permite abstraer al usuario de errores. Tambien permite que en caso de ser necesario incluir mayor capacidad o nodos de ejeución esto sea imperceptible para el usuario.

• Bajo Acoplamiento dado que se se utilizan componentes intermediarios en el caso de las colas Pub/Sub que permite asbtraer el funcionamiento de las notificaciones.

• Alta Cohesion y principio de responsabilidad unica ya que cada componete esta pensando para cumplir una funcion dentro del dominio del negocio agrupando las funcionalidades que estan asociadas a este dominio.

Razonamiento sobre Principales decisiones de Diseño

Decision de Diseño	Razonamiento
Balanceo de Carga	Esta desicion de diseño favorece el manejo de redundancia activa maneteneniendo varios nodos disponibles para atender el incremento de peticiones de los usuarios.
Incrementar Recursos	Esta desicion de diseño permite que el sistema automaticamente escale ante un incremento de peticioes o usuarios cocurrentes, esto puede ser programado o automatico manteniendo un minimo ó maximo segun lo identificado en estadisticas o experimentos.
Replicación Recursos	Esta desicion de diseño permite que el sistema este disponible en multiples regiones o zonas geograficas, en caso de una falla en una zona el sistema continuara disponible ya que la otra zona seguira atendiendo solicitudes, esto combinado con la tactica de incrementar recursos permitira mantener una operacion estable asbtrayendo cualquier falla al usuario.