Design

Propuesta:

Open

PODs dentro de un cluster de Kubernetes con reglas de escalamiento y resiliencia (normalmente ambientes productivos son 3 instancias), los servicios CORE no están expuestos, solo pueden ser alcanzados dentro del mismo cluster, ya sea por un servicio de canal o entre ellos mismos (autenticación apikey); las apps CHANNEL están expuestas por un ALB el cual se encarga de políticas de seguridad de red y tiene rutas para limitar el acceso (solo a CHANNEL), estas apps tienen autenticación por JWT, ya que el objetivo es que sean consumidas por alguien/algo que tenga permiso para usarlas. El cluster de Mongo igual esta en nodos, primario (operación), secundario (respaldo y lectura), en caso de ser necesario se podría tener una política de datos en frío para reducir gastos e incrementar performace. Las llamadas a la capa de CORE cuentan con cache (excepto users y roles).

Nota: las propiedades necesarias para la convivencia del ecosistema se encontraran en secrets dentro del cluster, para que los servicios puedan arrancar con los valores necesarios para comunicarse, por ejemplo: apikey, llave JWT, conexiones BD, llaves encriptación.

Bonus:

Proceso async que lee archivos con registros masivos, utiliza una QUEUE para que el lambda tenga posibilidad de trabajar modo batch y con reproceso en caso de no tener éxito.

Responsabilidades:

auth-app: gestión de usuario (login, logout, signin, interactions), su trabajo principal es generar el JWT (conteniendo datos del perfil), para poder consumir las APIs de CHANNEL correspondientes a cada perfil

sell-app: generación de ventas (buscar producto disponible, generar orden, pagar orden, seguimiento de orden), end2end de una compra

service-app: interface para proveedor (disponibilizar productos y servicios), generar conexión de producto + orden + pago + entrega, considerando proveedores del servicio de entrega

Comunicación:

REST

JPA (repository)