Visión General de la Arquitectura

La arquitectura está diseñada bajo un enfoque de microservicios desacoplados, distribuidos geográficamente para garantizar resiliencia y baja latencia. El flujo general es el siguiente:

• Los clientes (web y móvil) acceden al sistema a través de una red perimetral global de Google.

• El tráfico es recibido por un Balanceador de Carga que lo dirige al API Gateway.

• El API Gateway actúa como punto único de entrada, aplicando políticas de seguridad (autenticación y autorización) antes de enrutar las peticiones.

• Las peticiones se procesan de forma asíncrona a través de Google Pub/Sub, que actúa como un bus de mensajería, desacoplando los servicios de front-end de los de back-end.

• Los microservicios, desplegados en un clúster de Google Kubernetes Engine (GKE), se suscriben a los mensajes de Pub/Sub para ejecutar la lógica de negocio.

• Los datos se persisten en una base de datos Cloud SQL (PostgreSQL) y en Cloud Storage, con réplicas en una región secundaria para recuperación ante desastres.

Diseño Detallado por Capas y Patrones Aplicados

1. Capa Perimetral y de Entrega de Contenido

• Esta capa es el primer punto de contacto para los usuarios y es fundamental para el rendimiento y la primera línea de defensa.

• Componentes Clave: Cloud CDN, Cloud Load Balancing.

• Patrones y Tácticas:

• Patrón de Red de Entrega de Contenido (CDN): Se utiliza Cloud CDN para cachear y servir contenido estático (imágenes, JS, CSS) desde ubicaciones cercanas al usuario.

• Balanceador de Carga Global: Cloud Load Balancing utiliza una dirección IP Anycast para dirigir a los usuarios al punto de presencia de Google más cercano, distribuyendo el tráfico de manera eficiente hacia la región primaria.

• Relación con los ASRs:

• Disponibilidad: Al distribuir el tráfico, el balanceador evita que un único punto de entrada se convierta en un cuello de botella o un punto único de fallo. El CDN reduce la carga en los servicios de backend, mejorando su disponibilidad.

• Rendimiento (ASR Secundario): Ambos componentes reducen drásticamente la latencia para los usuarios finales a nivel global.

2. Capa de Acceso y Seguridad

• Esta capa protege el sistema, garantizando que solo las solicitudes legítimas y autorizadas lleguen a la lógica de negocio.

• Componentes Clave: API Gateway, Identity Platform, Autorizador, Certificador.

• Patrones y Tácticas:

• Patrón API Gateway: Actúa como una fachada única para todos los servicios internos. Esto simplifica la gestión de los clientes, centraliza la aplicación de políticas transversales y desacopla la arquitectura interna de los consumidores externos.

• Táctica de Seguridad (Autenticación): El API Gateway delega la autenticación a Google Identity Platform, que implementa el flujo estándar de OAuth2/OIDC. Esto centraliza la gestión de usuarios y credenciales.

• Táctica de Seguridad (Autorización Centralizada): Una vez autenticado, el API Gateway invoca al servicio Autorizador. Este componente valida el Token (JWT) de la solicitud y verifica si el usuario tiene los permisos necesarios para realizar la acción, implementando un control de acceso basado en roles (RBAC) o atributos (ABAC).

• Táctica de Seguridad (Certificados): El componente Certificador es responsable de la gestión centralizada de certificados TLS/mTLS, garantizando que toda la comunicación (tanto externa como interna entre microservicios) esté cifrada.

• Relación con los ASRs:

• Seguridad: Este diseño implementa directamente las tres tácticas de seguridad requeridas: Autenticación robusta, Autorización explícita y centralizada, y comunicación segura mediante Certificados.

3. Capa de Aplicación (Microservicios)

• El núcleo de la lógica de negocio reside en esta capa, diseñada para ser escalable, resiliente y mantenible.

• Componentes Clave: Google Kubernetes Engine (GKE), Microservicios contenerizados (Ventas, Inventario, etc.), Google Pub/Sub.

• Patrones y Tácticas:

• Patrón de Arquitectura de Microservicios: La aplicación se descompone en servicios pequeños, autónomos y enfocados en un dominio de negocio específico. Esto permite que los equipos desarrollen, desplieguen y escalen sus servicios de forma independiente.

• Patrón de Mensajería Publicador/Suscriptor (Pub/Sub): En lugar de comunicación síncrona directa, el API Gateway publica eventos en temas de Pub/Sub. Los microservicios se suscriben a los temas de interés y reaccionan a los eventos. Este desacoplamiento es vital.

• Táctica de Disponibilidad (Múltiples Copias de Computación): Esta es la táctica central de disponibilidad. Se implementa en GKE mediante el Horizontal Pod Autoscaler (HPA), que garantiza un número mínimo de réplicas (>=2) para cada microservicio y crea nuevas réplicas automáticamente bajo carga. Además, los nodos del clúster se distribuyen en múltiples zonas de disponibilidad para protegerse contra fallos a nivel de centro de datos.

Relación con los ASRs:

Disponibilidad: El patrón Pub/Sub asegura que si un microservicio consumidor falla, los mensajes permanecen en la cola hasta que el servicio se recupere, evitando la pérdida de datos. La táctica de Múltiples Copias en GKE garantiza que no haya un punto único de fallo a nivel de aplicación y que el sistema pueda escalar para soportar picos de demanda.

4. Capa de Datos y Persistencia

• Esta capa es responsable del almacenamiento seguro y resiliente de los datos.

• Componentes Clave: Cloud SQL (PostgreSQL), Cloud Storage.

• Patrones y Tácticas:

• Patrón de Réplica de Lectura (Read Replica): Se mantiene una réplica asíncrona de la base de datos principal en una región geográfica diferente.

• Almacenamiento de Objetos para Datos no Estructurados: Se utiliza Cloud Storage para almacenar archivos binarios como evidencias o documentos. El acceso se controla mediante Signed URLs para proporcionar acceso seguro y temporal.

Relación con los ASRs:

Disponibilidad y Durabilidad: La réplica de lectura es clave para la estrategia de Recuperación ante Desastres (DR). En caso de un fallo total de la región primaria, el sistema puede conmutar a la región de DR, cumpliendo con el RTO (< 6h). Las copias de seguridad automáticas gestionadas por GCP protegen contra la corrupción o pérdida de datos.

Seguridad: El uso de Signed URLs para Cloud Storage evita la exposición pública de los objetos, garantizando que solo los usuarios con un enlace válido y de tiempo limitado puedan acceder a ellos.

Conclusión

El diseño de esta arquitectura combina estratégicamente patrones de diseño probados y servicios gestionados de GCP para construir un sistema que cumple de forma nativa con los requisitos de alta disponibilidad y seguridad. La disponibilidad se logra a través de la redundancia en cada capa, mientras que la seguridad se aborda con un enfoque de defensa en profundidad, desde la autenticación en el borde hasta la autorización centralizada y el cifrado de comunicación interna.