Request Governance and Backend Execution

Shows how an authorized request moves through traffic protection, write-safety controls, and backend invocation while preserving consistent external semantics.

6. Request Processing Flow

6.1 Request Governance and Execution Layer

The Request Governance and Execution Layer accepts only authorized requests output by Section 5.6. Low-cost checks that protect system capacity happen first, and cryptographic validation for payment write requests occurs later. The second execution point of the Traffic Routing Policy Center selects a backend only after identity, route, and request type are all trusted.

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 32, "rankSpacing": 38, "htmlLabels": true}}}%% flowchart TB INPUT["Authorized request Trusted identity + Scope · route · request_class"] --> RATE["Layered rate limiting Source IP · Key · Merchant · Platform"] RATE --> IDEMPOTENCY{"Write request or route requires idempotency?"} IDEMPOTENCY -->|"Yes"| IDEM_CHECK["Validate Idempotency-Key syntax Pass through only · Backend owns deduplication"] IDEMPOTENCY -->|"No"| WRITE_SECURITY IDEM_CHECK --> WRITE_SECURITY{"Production payment-write route?"} WRITE_SECURITY -->|"Yes"| PROOF["Proof of possession Ed25519 signature + Nonce or post-authentication mTLS certificate-binding validation"] WRITE_SECURITY -->|"No"| ROUTE PROOF --> ROUTE["Execution point 2 · Backend selection Healthy candidates · Read-consistency gates Writer and cross-region write gates"] ROUTING["Traffic Routing Policy Center Backend candidates and failover policy"] -.-> ROUTE ROUTE --> HEADERS["Remove externally forged internal identity headers Inject gateway-signed identity context"] HEADERS --> CALL["Invocation policy Timeout caps · Circuit breaking · Bounded retries No automatic retry for non-idempotent writes"] CALL --> PLATFORM["One explicit payment-platform backend"] PLATFORM --> RESPONSE["Response normalization Stable error codes + 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

The mTLS handshake occurs at the actual TLS termination point described in Section 4.1. This layer only verifies whether certificate context is explicitly bound to the authenticated API Key. If Ed25519 Nonce state is unavailable and backend global-idempotency capability has not been verified, payment write requests fail closed. The routing execution point emits one target only; the gateway does not dual-write to multiple business databases.

Request Sequence Across Abstract Nodes

sequenceDiagram participant M as Merchant system participant I as Unified Ingress Layer participant A as Access Control Center participant C as Local configuration snapshot cache participant G as Request Governance and Execution Layer participant S as Payment platform service M->>I: TLS request and API Key I->>I: Entry selection, DDoS, TLS, WAF, protocol, and trusted source I->>A: Canonical request, trusted source IP, and mTLS context A->>A: Create request_id and hold route-match result temporarily A->>C: Read versioned authorization snapshot C-->>A: Key digest, status, bindings, Scope, and version A->>A: Determine identity, Key-IP, route visibility, and Scope alt Identity and route authorization succeed A->>G: Authorized request and trusted identity context G->>G: Rate limiting, idempotency, payment-write security, and backend selection G->>S: Forward request and trusted identity context S-->>G: Platform response G-->>I: Normalized response I-->>M: Return stable response else Identity or IP authentication denied A-->>I: Uniform 401 without exposing specific security configuration I-->>M: Return 401 and request_id else Route absent or Scope insufficient A-->>I: Uniform 404 without exposing route visibility I-->>M: Return 404 and request_id end

This sequence diagram only shows ordering and the 401/404 branches across abstract boundaries and key dependencies. It does not repeat each node's internal checks. The local configuration snapshot cache is an internal dependency of the Access Control Center, not a new abstract boundary. The Traffic Routing Policy Center is not a synchronous participant: execution point 1 is inside the Unified Ingress Layer, and execution point 2 is inside the Request Governance and Execution Layer.

Every request is processed in this fixed order:

The edge layer completes TLS, WAF, and basic protocol validation and obtains the trusted source IP.
The gateway assigns a globally unique request_id and normalizes the path, method, and request headers.
The gateway may hold an internal route-match result temporarily, but it must not use that result to return different responses before authentication is complete.
The API Key validation service parses the public Key ID, retrieves the configuration snapshot, and validates the Secret digest.
Validate the Key's merchant ownership, ingress environment, status, activation time, and expiration time.
Validate that the source IP has an explicit binding to the Key. Failure of any preceding authentication step returns a uniform 401.
Process the route-match result after authentication succeeds. Return a uniform 404 when a route is absent or the Key lacks its required scope, preventing route enumeration.
Apply additional policies to visible routes. A business-policy denial explicitly allowed to be disclosed may return 403.
Enforce Key-level and merchant-level rate limits. The gateway requires and validates the length and character format of Idempotency-Key only when request_class is write or a route policy explicitly requires idempotency. The gateway passes the value through only, does not store deduplication state, and the backend platform detects content conflicts and returns 409.
For payment write requests, perform the mTLS or Ed25519 request-signature validation required by Section 5.5.
Select one target instance according to merchant routing partition, service capability declaration, and backend health state.
Remove externally forged internal identity headers and write gateway-signed merchant, Key, Scope, region, and request identifiers.
Apply capped connection, request, and response timeouts and do not automatically retry non-idempotent write requests.
Write structured access logs, authorization-decision logs, metrics, and distributed traces.

6.2 External Error Semantics

HTTP status	Scenario	External information
`400`	Invalid protocol, field, or idempotency key	Return a stable error code and request_id
`401`	Key missing, malformed, unknown, Secret mismatch, invalid status, wrong environment, or unbound IP	Return a uniform authentication failure without distinguishing the specific cause
`403`	Identity and route are visible, but an explicitly discloseable additional business policy denies access	Return a stable access-denied code without disclosing security configuration
`404`	The route does not exist, or the authenticated Key lacks the route's required scope	Use the same response for both cases to prevent route enumeration
`409`	The backend platform determines that an idempotency key conflicts with the content of an existing request	The gateway passes through the stable conflict code and does not store deduplication state
`429`	Merchant or Key exceeds rate-limit policy	Return a retry time that is safe to disclose
`502`	Backend protocol error	Return request_id
`503`	Authorization component or target service unavailable	Return request_id and a retryable marker
`504`	Backend timeout	Return request_id and a retryable marker

Internal logs retain the exact reason_code, but external responses do not disclose whether a Key exists, which IPs are bound, or which permissions are held.