Gobernanza de solicitudes y ejecución del backend

Explica cómo las solicitudes autorizadas atraviesan la protección de tráfico, los controles de seguridad para escrituras y las llamadas al backend, conservando una semántica externa estable.

6. Flujo de procesamiento de solicitudes

6.1 Capa de gobierno y ejecución de solicitudes

La capa de gobierno y ejecución de solicitudes solo recibe solicitudes autorizadas emitidas por la sección 5.6. Las comprobaciones baratas que protegen la capacidad del sistema se hacen antes y la validación criptográfica de solicitudes de escritura de pagos se hace después; el segundo punto de ejecución del centro de políticas de enrutamiento solo elige un backend cuando identidad, ruta y tipo de solicitud son confiables.

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 32, "rankSpacing": 38, "htmlLabels": true}}}%% flowchart TB INPUT["Solicitud autorizada identidad confiable + Scope · route · request_class"] --> RATE["Limitación de tasa por capas IP de origen · Key · comerciante · plataforma"] RATE --> IDEMPOTENCY{"¿Solicitud de escritura o ruta que exige idempotencia?"} IDEMPOTENCY -->|"sí"| IDEM_CHECK["Validar sintaxis de Idempotency-Key solo transmitir · deduplicación propiedad del backend"] IDEMPOTENCY -->|"no"| WRITE_SECURITY IDEM_CHECK --> WRITE_SECURITY{"¿Ruta de escritura de pagos en producción?"} WRITE_SECURITY -->|"sí"| PROOF["Prueba de posesión firma Ed25519 + Nonce o validar vinculación del certificado mTLS después de autenticar"] WRITE_SECURITY -->|"no"| ROUTE PROOF --> ROUTE["Punto de ejecución 2 · selección de backend candidatos saludables · control de coherencia de lectura controles de writer y escritura interregional"] ROUTING["Centro de política de enrutamiento de tráfico candidatos de backend y política de conmutación"] -.-> ROUTE ROUTE --> HEADERS["Eliminar encabezados de identidad interna falsificados desde el exterior inyectar contexto de identidad firmado por el gateway"] HEADERS --> CALL["Política de llamada límite de tiempo · disyuntor · reintentos acotados sin reintento automático para escrituras no idempotentes"] CALL --> PLATFORM["Un backend de plataforma de pagos concreto"] PLATFORM --> RESPONSE["Normalización de respuesta códigos de error estables + request_id"] classDef input fill:#F4F7FB,stroke:#72849A,color:#253954,stroke-width:1.5px classDef runtime fill:#FFFFFF,stroke:#4F79A7,color:#18212F,stroke-width:1.5px classDef policy fill:#EDF8F3,stroke:#16835E,color:#124D3B,stroke-width:1.5px classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px class INPUT,ROUTING input class RATE,IDEMPOTENCY,IDEM_CHECK,WRITE_SECURITY,PROOF,HEADERS,CALL,RESPONSE runtime class ROUTE policy class PLATFORM external

El handshake mTLS ocurre en el punto de terminación TLS real descrito en la sección 4.1; aquí solo se valida si el contexto de certificado está explícitamente vinculado a la API Key autenticada. Si el estado de Nonce de Ed25519 no está disponible y no se ha verificado la capacidad de idempotencia global del backend, las solicitudes de escritura de pagos fallan en modo cerrado. El punto de ejecución de enrutamiento solo entrega un destino; el gateway no realiza escrituras dobles en varias bases de datos de negocio.

Secuencia de solicitud entre nodos abstractos

sequenceDiagram participant M as Sistema del comerciante participant I as Capa de acceso unificada participant A as Centro de control de acceso participant C as Caché de instantánea de configuración regional participant G as Capa de gobierno y ejecución de solicitudes participant S as Servicio de plataforma de pagos M->>I: Solicitud TLS y API Key I->>I: Selección de entrada, DDoS, TLS, WAF, protocolo y origen confiable I->>A: Solicitud normalizada, IP de origen confiable y contexto mTLS A->>A: Generar request_id y conservar temporalmente el resultado de coincidencia de ruta A->>C: Leer instantánea de autorización versionada C-->>A: Resumen de Key, estado, vinculaciones, Scope y versión A->>A: Decisión de identidad, Key-IP, visibilidad de ruta y Scope alt Autorización de identidad y ruta aprobada A->>G: Solicitud autorizada y contexto de identidad confiable G->>G: Limitación de tasa, idempotencia, seguridad de escritura de pagos y selección de backend G->>S: Reenviar solicitud y contexto de identidad confiable S-->>G: Respuesta de plataforma G-->>I: Respuesta normalizada I-->>M: Devolver respuesta estable else Denegación de autenticación de identidad o IP A-->>I: 401 uniforme, sin exponer configuración de seguridad específica I-->>M: Devolver 401 y request_id else Ruta inexistente o Scope insuficiente A-->>I: 404 uniforme, sin exponer visibilidad de ruta I-->>M: Devolver 404 y request_id end

Este diagrama de secuencia solo expresa el orden entre los límites abstractos y dependencias clave, además de las ramas 401/404, y no repite las comprobaciones internas de cada nodo. La caché de instantánea de configuración regional es una dependencia interna del centro de control de acceso, no un nuevo límite abstracto. El centro de política de enrutamiento de tráfico no participa como actor sincrónico: el punto de ejecución 1 ya está incluido en la capa de acceso unificada y el punto de ejecución 2 ya está incluido en la capa de gobierno y ejecución de solicitudes.

Cada solicitud se procesa en el siguiente orden fijo:

La capa perimetral completa TLS, WAF y validación básica de protocolo y obtiene una IP de origen confiable.
El gateway asigna un request_id globalmente único y normaliza ruta, método y encabezados de solicitud.
El gateway puede conservar temporalmente el resultado de coincidencia de ruta interna, pero no puede devolver una respuesta distinta según ese resultado antes de completar la autenticación.
El servicio de validación de API Key analiza el Key ID público, obtiene la instantánea de configuración y valida el resumen del Secret.
Valida pertenencia del comerciante de la Key, entorno de entrada, estado, momento de vigencia y vencimiento.
Valida si la IP de origen tiene una vinculación explícita con la Key; el fallo de cualquiera de los pasos anteriores de autenticación devuelve uniformemente 401.
Después de autenticar correctamente, procesa el resultado de coincidencia de ruta; si la ruta no existe o a la Key le falta el required scope, devuelve uniformemente 404 para evitar enumeración de rutas.
Ejecuta políticas adicionales para rutas visibles; una denegación de política de negocio cuyo detalle esté explícitamente permitido puede devolver 403.
Ejecuta limitación de tasa por Key y por comerciante. Solo cuando request_class es escritura o la política de ruta exige explícitamente idempotencia, el gateway hace obligatorio Idempotency-Key y valida su longitud y formato de caracteres; el gateway solo transmite el valor, no conserva estado de deduplicación, y la plataforma de backend detecta conflictos de contenido y devuelve 409.
Ejecuta la validación de firma de solicitud mTLS o Ed25519 definida en la sección 5.5 para solicitudes de escritura de pagos.
Selecciona una instancia destino según la partición de enrutamiento del comerciante, la declaración de capacidad de servicio y el estado de salud del backend.
Elimina encabezados internos de identidad falsificados desde el exterior y escribe comerciante, Key, Scope, región e identificador de solicitud firmados por el gateway.
Ejecuta tiempos máximos de espera de conexión, solicitud y respuesta, sin reintentar automáticamente solicitudes de escritura no idempotentes.
Escribe registros de acceso estructurados, registros de decisión de autorización, métricas y trazas distribuidas.

6.2 Semántica de errores externa

Estado HTTP	Caso de uso	Información externa
`400`	Protocolo, campo o clave de idempotencia no válidos	Devuelve código de error estable y request_id
`401`	Key ausente, formato incorrecto, desconocida, Secret no coincidente, estado no válido, entorno no coincidente o IP no vinculada	Devuelve uniformemente fallo de autenticación sin distinguir la causa concreta
`403`	Identidad y ruta visibles, pero denegación explícitamente divulgable de política de negocio adicional	Devuelve un código estable de acceso denegado sin revelar configuración de seguridad
`404`	La ruta no existe o la Key autenticada carece del required scope de esa ruta	Los dos casos utilizan la misma respuesta para evitar enumeración de rutas
`409`	La plataforma de backend determina que la clave de idempotencia entra en conflicto con el contenido de una solicitud existente	El gateway transmite el código de conflicto estable sin conservar estado de deduplicación
`429`	El comerciante o la Key supera la política de limitación de tasa	Devuelve un tiempo de reintento que puede divulgarse de forma segura
`502`	Error de protocolo de backend	Devuelve request_id
`503`	El componente de autorización o el servicio destino no están disponibles	Devuelve request_id y una marca de que puede reintentarse
`504`	Tiempo de espera agotado en el backend	Devuelve request_id y una marca de que puede reintentarse

Los registros internos conservan el reason_code preciso, pero las respuestas externas no revelan si la Key existe, a qué IP está vinculada ni qué permisos posee.