Partiendo de los límites generales de responsabilidad, explica cómo una solicitud entra de forma segura en una región apta y qué responsabilidad corresponde a cada tipo de componente.
4. Arquitectura general
El siguiente diagrama solo expresa los límites lógicos de responsabilidad y los elementos entregados entre límites; no detalla componentes, cachés ni topología de despliegue. Los seis nodos neutrales pueden implementarse mediante varios componentes o desplegarse de forma distribuida; el término "centro" en sus nombres indica reglas unificadas y propiedad de responsabilidad, no que una solicitud deba invocar sincrónicamente un servicio centralizado.
Vista general de límites lógicos
Las líneas continuas de la vista general representan relaciones de entrega de solicitudes o instantáneas versionadas; las líneas discontinuas representan influencia de política o agregación de eventos. El centro de política de enrutamiento de tráfico no es un servicio sincrónico centralizado en la ruta crítica: el punto de ejecución de entrada elige la región de entrada y el punto de ejecución de gobierno, después de la autenticación, elige el backend y aplica los controles de conmutación. El centro de observabilidad y auditoría no reemplaza la escritura de auditoría dentro de la transacción del plano de control; solo se ocupa de agregación segura, consultas correlacionadas, alertas y salida de evidencia. La vista general no muestra una caché separada; la instantánea regional es una implementación interna del control de acceso y del gobierno de solicitudes, y su origen siempre es la cadena de publicación de configuración.
| Nodo abstracto | Responsabilidad única | Ubicación de detalle |
|---|---|---|
| Capa de acceso unificada | Lleva conexiones externas de forma segura a una región elegible y produce un contexto de origen confiable | Sección 4.1 |
| Centro de política de enrutamiento de tráfico | Restringe la región de entrada y la selección de backend posterior a la autenticación con una política versionada | Sección 7.1.1 |
| Centro de control de acceso | Completa la decisión de identidad, Key-IP y Scope de ruta y entrega una semántica estable de permitir o denegar | Sección 5.6 |
| Capa de gobierno y ejecución de solicitudes | Aplica políticas de tráfico, seguridad y llamadas a solicitudes autorizadas, e invoca un backend concreto | Sección 6.1 |
| Centro de publicación y operaciones de configuración | Valida cambios administrativos, persiste con escritura única, publica instantáneas y proporciona un canal de denegación de emergencia independiente | Sección 10.1 |
| Centro de observabilidad y auditoría | Agrega eventos con datos sensibles eliminados y produce consultas correlacionadas, alertas, SLO y evidencia de cumplimiento | Sección 12.1 |
4.1 Capa de acceso unificada
La capa de acceso unificada incluye productos globales de tráfico, protección perimetral, puntos de terminación TLS o rutas de paso, entradas regionales y balanceo de carga. Solo establece conexiones confiables y contexto de origen; no autentica API Key ni concede permisos de plataforma. Una indicación de comerciante o plataforma antes de la autenticación solo puede reducir el conjunto de candidatos de entrada.
El contexto del certificado mTLS de la salida es solo el resultado del handshake; la vinculación explícita entre el certificado y la API Key debe validarse después de que la autenticación de identidad haya tenido éxito. Si el TLS externo termina en el WAF o pasa al gateway sigue siendo una decisión de selección técnica; independientemente del punto de terminación, se debe aplicar ocultación de credenciales, protección de certificados y validación de la cadena de proxies confiables.
4.2 Componentes del plano de datos
- Centro de política de enrutamiento de tráfico (capacidad lógica): define de manera unificada las políticas de región de entrada y de enrutamiento de backend dentro de la región, y las publica como instantáneas versionadas para evaluación local en dos puntos de ejecución, sin introducir dependencia de una base de datos sincronizada entre regiones.
- Entrada global, WAF y balanceo de carga: el punto de ejecución de entrada selecciona la región de entrada según la política publicada y la salud regional; WAF y balanceo se encargan de la protección DDoS, la terminación o el paso TLS, validación básica de protocolo y distribución de instancias dentro de la región.
- API Gateway: completa normalización de solicitudes, llamada de autenticación, ejecución de permisos, limitación de tasa, enrutamiento, tiempo de espera, disyuntor, identificación de solicitud y normalización de respuestas.
- Servicio de validación de API Key (desplegado en cada región): valida resumen del Secret, estado de la Key, entorno de entrada y vinculación Key-IP, y devuelve al gateway la identidad verificada y el conjunto de Scope; no determina si un comerciante puede acceder a una ruta.
- Instantánea de configuración regional y caché de limitación de tasa: conserva instantáneas firmadas o versionadas de Key, IP, Scope, revocación y rutas, además del estado de limitación de tasa distribuida. El Nonce de escrituras de pago usa una caché de seguridad independiente, sincronizada solo entre regiones donde se permite la conmutación de escrituras.
- Capa de enrutamiento de servicio: como segundo punto de ejecución posterior a la autenticación, mantiene endpoints de backend regionales, estado de salud, límites de reintento y ejecuta los controles de conmutación interregional publicados por el centro de políticas.
4.3 Componentes del plano de control
- Gateway Admin API: proporciona interfaces invocables por máquina para el ciclo de vida de Key, Scope, vinculaciones IP y gestión de rutas.
- Identidad y aprobación internas: los administradores deben iniciar sesión mediante el sistema de identidad corporativo; las operaciones de alto riesgo requieren aprobación de dos personas.
- Plano de control unificado: valida invariantes de configuración, mantiene un arrendamiento de escritura única, escribe en PostgreSQL y publica eventos de cambio versionados mediante el Outbox transaccional.
- PostgreSQL: única fuente de verdad para comerciantes, Key, permisos, vinculaciones y configuración de rutas; utiliza replicación activa y de reserva entre regiones y vallado de escritura.
- Plano de control de reserva: normalmente no acepta escrituras; solo puede asumir el control cuando el primario anterior ha sido vallado y obtiene un nuevo epoch.
- Bus de mensajes: envía cambios a cada región y admite reproducción, posiciones de consumo y consumo idempotente.
- Entrada break-glass de solo denegación: cuando el plano de control no está disponible, añade elementos de denegación de emergencia a los servicios regionales de validación de API Key; nunca puede ampliar permisos.
- Almacenamiento de auditoría: registra quién realizó qué cambio, cuándo y por qué, junto con diferencias no sensibles antes y después del cambio.
4.4 Línea base tecnológica recomendada
En ausencia de restricciones de una pila tecnológica existente, se recomienda adoptar primero la siguiente línea base para validación de prototipo:
- Proxy del plano de datos: Envoy Gateway o un proxy L7 maduro equivalente.
- Validación de API Key: un servicio de validación externo e independiente gestiona el resumen de credenciales, el estado de la Key, el entorno y la vinculación Key-IP; la política del gateway ejecuta visibilidad de ruta y required scope, evitando codificar la lógica de validación en la configuración del proxy.
- Base de datos principal de configuración: PostgreSQL.
- Instantánea de configuración regional y limitación de tasa: clúster compatible con Redis.
- Distribución de configuración: bus de mensajes compatible con Kafka y Outbox transaccional de PostgreSQL.
- Plataforma de despliegue: Kubernetes, con despliegue multizona de disponibilidad y reglas de anti-afinidad de Pod.
- Protección de secretos: KMS en la nube o servicio equivalente de gestión de claves protegido por hardware.
Esta línea base tecnológica debe confirmarse tras recibir del equipo de plataforma el inventario de infraestructura existente. La arquitectura lógica no depende de productos de un proveedor concreto.