System Architecture and Unified Entry Layer

Shows how a request enters an eligible region safely and clarifies the responsibility of each logical component.

4. Overall Architecture

The following diagram expresses only logical responsibility boundaries and what is delivered across those boundaries. It does not expand individual components, caches, or deployment topology. The six neutral nodes can be implemented by multiple components or deployed separately. “Center” in a node name means unified rules and responsibility ownership; it does not mean every request must synchronously call one centralized service.

Logical Boundary Overview

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 34, "rankSpacing": 44, "htmlLabels": true}}}%% flowchart TB subgraph CONTROL["Policy and Configuration"] direction LR CONFIG["Configuration Publishing and Operations Center Management changes · Version publishing · Emergency deny-only"] -->|"Routing policy snapshot"| ROUTING["Traffic Routing Policy Center One policy · Two execution points"] end subgraph REQUEST["Merchant Request Path"] direction LR MERCHANT["Merchant system"] --> INGRESS["Unified Ingress Layer Entry selection · Edge protection · Trusted source"] INGRESS --> ACCESS["Access Control Center Authentication · Key-IP · Scope"] ACCESS --> GOVERN["Request Governance and Execution Layer Traffic policy · Security gates · Backend invocation"] GOVERN --> PLATFORM["Payment platform services WebPay Inbox · BPS · Zero Confirmation"] end ROUTING -.->|"Ingress-region policy"| INGRESS ROUTING -.->|"Backend candidates and failover gates"| GOVERN CONFIG -->|"Key · IP · Scope snapshots"| ACCESS CONFIG -->|"Routing-governance snapshots"| GOVERN GOVERN -.->|"Data-plane runtime and decision events"| OBSERVE["Observability and Audit Center Correlation queries · Alerts · SLOs · Compliance evidence"] CONFIG -.->|"Change events and in-transaction audit"| OBSERVE classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px classDef entry fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:2px 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 control fill:#F2F0FF,stroke:#6657C7,color:#292057,stroke-width:1.5px class MERCHANT,PLATFORM external class INGRESS entry class ACCESS,GOVERN runtime class ROUTING,OBSERVE policy class CONFIG control style CONTROL fill:#FAF9FF,stroke:#C9C0F1,stroke-width:2px style REQUEST fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px

Solid lines in the overview represent request or versioned-snapshot delivery relationships. Dotted lines represent policy influence or event aggregation relationships. The Traffic Routing Policy Center is not a centralized synchronous service on the request hot path: the ingress execution point selects the ingress region, and the post-authentication governance execution point selects the backend and applies failover gates. The Observability and Audit Center does not replace in-transaction audit writes in the control plane; it is responsible only for secure aggregation, correlation queries, alerting, and evidence output. The overview does not show caches as separate elements: local snapshots are internal implementations of access control and request governance, and their source is always the configuration-publishing path.

Abstract node	Single responsibility	Expanded in
Unified Ingress Layer	Safely delivers external connections into a qualified region and produces trusted-source context	Section 4.1
Traffic Routing Policy Center	Constrains ingress-region selection and post-authentication backend selection with one versioned policy	Section 7.1.1
Access Control Center	Performs identity, Key-IP, and route-Scope determination, producing stable allow or deny semantics	Section 5.6
Request Governance and Execution Layer	Applies traffic, security, and invocation policy to authorized requests and calls one explicit backend	Section 6.1
Configuration Publishing and Operations Center	Validates management changes, persists them through single-writer control, publishes snapshots, and provides an independent emergency deny channel	Section 10.1
Observability and Audit Center	Aggregates redacted events to provide correlation queries, alerts, SLOs, and compliance evidence	Section 12.1

4.1 Unified Ingress Layer

The Unified Ingress Layer includes global traffic products, edge protection, TLS termination points or pass-through paths, regional ingress, and load balancing. It establishes only trusted connections and source context; it does not authenticate API Keys or grant platform permissions. Merchant or platform hints before authentication may only reduce the ingress candidate set.

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 34, "rankSpacing": 38, "htmlLabels": true}}}%% flowchart TB MERCHANT["Merchant TLS request"] --> EDGE["Global edge protection L3/L4 DDoS · Connection and rate boundaries"] HINT["Unauthenticated routing hint Reduces candidates only · Grants no permission"] --> SELECT["Execution point 1 · Ingress-region selection allowed_regions · Compliance · Regional health"] POLICY["Routing Policy Center Ingress-region policy version"] -.-> SELECT EDGE --> SELECT SELECT -->|"A qualified region exists"| REGION["Regional ingress"] SELECT -->|"No qualified region"| FAIL["Stop resolution or return 503 Determined by global traffic-product capability"] subgraph REGIONAL["Ingress processing inside a qualified region"] direction LR REGION --> TLS["TLS termination or pass-through mTLS handshake completes at the actual termination point"] TLS --> WAF["L7 WAF and protocol boundary Method · Header · Path · Message size"] WAF --> SOURCE["Trusted source IP Overwrite external forwarding headers · Validate trusted proxy chain"] SOURCE --> BALANCE["Intra-region load balancing Select healthy gateway instances only"] BALANCE --> OUTPUT["Output Canonical request + trusted source IP mTLS certificate context"] end classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px classDef input fill:#F4F7FB,stroke:#72849A,color:#253954,stroke-width:1.5px classDef entry fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:1.5px classDef reject fill:#FFF2EC,stroke:#C7582B,color:#6B2812,stroke-width:1.5px class MERCHANT external class HINT,POLICY input class EDGE,SELECT,REGION,TLS,WAF,SOURCE,BALANCE,OUTPUT entry class FAIL reject style REGIONAL fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px

The mTLS certificate context in the output is only the handshake result. Explicit binding between the certificate and the API Key must be checked after identity authentication succeeds. Whether external TLS terminates at the WAF or passes through to the gateway remains a technology-selection decision; regardless of the termination point, credential redaction, certificate protection, and trusted-proxy-chain validation are mandatory.

4.2 Data-Plane Components

Traffic Routing Policy Center (logical capability): centrally defines ingress-region and in-region backend-routing policy, and publishes versioned snapshots for local evaluation at two execution points without adding a synchronous cross-region database dependency.
Global ingress, WAF, and load balancing: the ingress execution point selects an ingress region based on published policy and regional health; the WAF and load balancer provide DDoS protection, TLS termination or pass-through, basic protocol validation, and in-region instance distribution.
API Gateway: performs request normalization, authentication calls, permission enforcement, rate limiting, routing, timeouts, circuit breaking, request identification, and response normalization.
API Key validation service, deployed in every region: validates Secret digest, Key status, ingress environment, and Key-IP bindings, returning a verified identity and Scope set to the gateway. It does not decide whether a merchant may access a route.
Local configuration snapshots and rate-limit cache: stores signed or versioned snapshots of Keys, IPs, Scopes, revocations, and routes, as well as distributed rate-limit state. Payment-write Nonces use a separate secure cache synchronized only among regions where write failover is permitted.
Service routing layer: acts as the second execution point after authentication, maintains in-region backend endpoints, health state, and retry boundaries, and enforces the cross-region failover gates published by the Policy Center.

4.3 Control-Plane Components

Gateway Admin API: provides machine-callable interfaces for Key lifecycle, Scope, IP-binding, and routing management.
Internal identity and approval: administrators must sign in through the company identity system; high-risk operations use dual approval.
Unified control plane: validates configuration invariants, holds the single-writer lease, writes to PostgreSQL, and publishes versioned change events through a transactional Outbox.
PostgreSQL: the sole source of truth for merchant, Key, permission, binding, and routing configuration; it uses active-and-standby cross-region replication and write fencing.
Standby control plane: does not accept writes under normal conditions and may take over only after the former primary is fenced and a new epoch is acquired.
Message bus: pushes changes to every region and supports replay, consumer offsets, and idempotent consumption.
Break-glass deny-only ingress: when the control plane is unavailable, appends emergency deny entries to the API Key validation service in every region and can never expand permissions.
Audit storage: records who made which change, when, and for what reason, including non-sensitive before-and-after differences.

4.4 Recommended Technology Baseline

In the absence of existing technology-stack constraints, begin prototype validation with the following baseline:

Data-plane proxy: Envoy Gateway or an equivalent mature L7 proxy.
API Key validation: a separate external validation service handles credential digests, Key status, environment, and Key-IP bindings; gateway policy enforces route visibility and required scopes, avoiding hard-coded validation logic in proxy configuration.
Configuration primary database: PostgreSQL.
Local configuration snapshots and rate limiting: Redis-compatible cluster.
Configuration distribution: Kafka-compatible message bus and PostgreSQL transactional Outbox.
Deployment platform: Kubernetes, deployed across multiple availability zones with Pod anti-affinity rules.
Secret protection: cloud KMS or an equivalent hardware-protected key-management service.

This technology baseline requires a technology-selection confirmation after the platform team provides its existing infrastructure inventory. The logical architecture does not depend on any specific vendor product.