Chapter 4. Architecture Design

Typical system topology, component wiring, deployment models, and scalability patterns

4.1 Typical System Topology

The authorization system topology is organized into four distinct zones that reflect the security and operational boundaries of a production deployment. The Client Zone encompasses all entry points — web browsers, mobile applications, API clients, and CLI tools — that initiate requests to the platform. The API Gateway and PEP Zone serves as the first enforcement layer, intercepting all inbound traffic and making authorization decisions before requests reach the resource services. The Authorization Plane contains the core decision-making components, and the Resource Services Zone contains the actual business logic services that the authorization system protects.

External dependencies are shown as a separate column to emphasize that they are owned by other teams or vendors and must be treated as external contracts with defined SLAs. The topology diagram illustrates both the request flow (from clients through the gateway to resource services) and the decision flow (from the PEP to the PDP and back), providing a complete picture of how authorization decisions are made and enforced in real time.

Figure 4.1: Typical Authorization System Topology — Four-zone architecture showing Client Zone, API Gateway & PEP Zone, Authorization Plane, Resource Services Zone, and External Dependencies with request and decision flows

Zone Responsibilities and Boundaries

Each zone has a clearly defined responsibility boundary that determines what decisions can be made within that zone and what must be delegated to another zone. The API Gateway and PEP Zone is responsible for authentication validation, rate limiting, and coarse-grained authorization decisions based on the user's role tier. Fine-grained decisions — including ABAC conditions, data-level controls, and obligation evaluation — are delegated to the Authorization Plane to keep the gateway layer fast and stateless.

The Authorization Plane is the only zone that has direct read access to the Policy Store, Role Catalog, and ABAC Library. This centralization ensures that policy changes propagate consistently to all enforcement points without requiring individual services to maintain their own policy copies. The Resource Services Zone implements a second enforcement layer at the service middleware level, providing defense-in-depth against bypass scenarios where a service might be called directly without going through the gateway.

4.2 Component Wiring and Interface Connections

The component wiring diagram shows the precise interface connections between all authorization system components, including the protocol used for each connection, the communication pattern (synchronous vs. asynchronous), and the caching relationships. Understanding these connections is essential for capacity planning, failure analysis, and debugging authorization issues in production.

The PDP Engine is the most connected component in the system, receiving synchronous gRPC calls from the PEP, reading from the Role Catalog and Permission Registry via cache, and emitting asynchronous audit events to the Audit Pipeline via Kafka. The Binding Manager publishes change events to the message bus whenever role assignments are modified, triggering cache invalidation across all PDP instances. This event-driven invalidation pattern ensures that revocations propagate within the configured TTL window without requiring synchronous coordination between components.

Figure 4.2: Component Wiring Diagram — Interface connections between all authorization components with protocol labels (REST/gRPC for synchronous, Kafka/AMQP for async events, dotted lines for cache reads) and legend

4.3 Deployment Models

The authorization system supports three primary deployment models, each suited to different organizational sizes, compliance requirements, and operational maturity levels. The selection of deployment model has significant implications for availability, latency, operational complexity, and cost, and should be made in conjunction with the infrastructure and security architecture teams.