Layrs

Gatekeeper Pattern: Protect Services with a Proxy

intermediate 27 min read Updated 2026-02-11

TL;DR

The Gatekeeper pattern uses a dedicated intermediary host to validate, sanitize, and broker all requests between clients and backend services. This security-focused proxy minimizes attack surface by ensuring untrusted traffic never directly reaches sensitive systems. Think of it as a security checkpoint that inspects every request before allowing it through.

Cheat Sheet: Gatekeeper = dedicated validation proxy → validates/sanitizes requests → forwards only clean traffic → protects backend from direct exposure → reduces attack surface.

The Analogy

Imagine a high-security government building where visitors can’t walk directly to offices. Instead, everyone must pass through a security checkpoint staffed by guards who check IDs, scan bags, and verify appointments before escorting approved visitors to their destination. The guards (gatekeeper) never let anyone bypass the checkpoint, and the people working inside (backend services) never interact directly with unvetted visitors. If someone tries to smuggle in prohibited items or lacks proper credentials, they’re stopped at the checkpoint—the offices inside remain completely isolated from the threat.

Why This Matters in Interviews

Gatekeeper comes up when discussing security architectures, especially for systems handling sensitive data (financial services, healthcare, government). Interviewers want to see you understand defense-in-depth strategies and can articulate the difference between a simple reverse proxy and a security-focused gatekeeper. Strong candidates explain when the overhead of a dedicated security layer is justified versus when simpler patterns suffice. This pattern often appears in discussions about PCI-DSS compliance, zero-trust architectures, or protecting legacy systems that can’t be easily hardened.

Core Concept

The Gatekeeper pattern establishes a dedicated security boundary between external clients and internal services by routing all traffic through a hardened intermediary host. Unlike a standard API gateway that focuses on routing and protocol translation, a gatekeeper’s primary purpose is security validation—it acts as the single enforcement point for authentication, authorization, input sanitization, and threat detection before any request reaches backend systems.

This pattern emerged from the principle of defense-in-depth: even if backend services have their own security measures, a gatekeeper provides an additional layer that can be independently hardened, monitored, and updated without touching production services. The gatekeeper host typically runs in a DMZ or isolated network segment with strict firewall rules, ensuring that backend services are never directly accessible from the internet or untrusted networks.

The key architectural decision is making the gatekeeper the only path to backend services. Backend systems should reject any traffic that doesn’t originate from the gatekeeper’s known IP addresses or carry cryptographic proof of gatekeeper validation. This creates a choke point where security policies can be uniformly enforced, logged, and audited—critical for compliance requirements like PCI-DSS, HIPAA, or SOC 2.

Gatekeeper Network Architecture (C4 Container)

graph TB
    subgraph Internet
        Client["External Client<br/><i>Untrusted Network</i>"]
    end
    
    subgraph DMZ - Public Subnet
        LB["Load Balancer<br/><i>ALB/NLB</i>"]
        GK1["Gatekeeper 1<br/><i>Security Proxy</i>"]
        GK2["Gatekeeper 2<br/><i>Security Proxy</i>"]
        GK3["Gatekeeper 3<br/><i>Security Proxy</i>"]
    end
    
    subgraph Private VPC - Backend Subnet
        API["API Service<br/><i>Business Logic</i>"]
        Payment["Payment Service<br/><i>Transactions</i>"]
        DB[("Database<br/><i>PostgreSQL</i>")]
        Cache[("Redis Cache<br/><i>Session Store</i>")]
    end
    
    Client --"HTTPS<br/>Public Internet"--> LB
    LB --"Distribute load"--> GK1 & GK2 & GK3
    GK1 & GK2 & GK3 --"Validated requests<br/>Private network only"--> API
    GK1 & GK2 & GK3 --"Validated requests"--> Payment
    API & Payment -."Direct access blocked<br/>by security groups".-> Client
    API --> DB
    Payment --> DB
    GK1 & GK2 & GK3 --> Cache

The gatekeeper sits in a DMZ between untrusted clients and private backend services. Backend services are configured to reject any traffic that doesn’t originate from gatekeeper IPs, creating a single enforcement point for all security policies. This network segmentation ensures attackers cannot bypass the gatekeeper.

How It Works

Step 1: Request Arrival A client sends a request to the gatekeeper’s public endpoint. The gatekeeper is the only component with a public IP address; backend services are completely isolated in private subnets. The gatekeeper immediately logs the request metadata (source IP, timestamp, headers) for audit trails.

Step 2: Authentication & Authorization The gatekeeper validates the client’s identity using tokens (JWT, OAuth), API keys, or mutual TLS certificates. It checks authorization policies stored in a centralized policy engine or cache—does this client have permission to access this resource? Failed auth attempts are logged and may trigger rate limiting or IP blocking.

Step 3: Input Validation & Sanitization The gatekeeper inspects the request payload against strict schemas and validation rules. It strips dangerous characters, validates data types, checks payload sizes, and scans for known attack patterns (SQL injection, XSS, command injection). This is where the gatekeeper acts as a web application firewall (WAF). Malformed or suspicious requests are rejected before they consume backend resources.

Step 4: Threat Detection Advanced gatekeepers integrate with threat intelligence feeds and anomaly detection systems. They check source IPs against blocklists, analyze request patterns for bot behavior, and apply rate limiting per client. Some implementations use machine learning models to detect zero-day attacks based on behavioral anomalies.

Step 5: Request Forwarding Once validated, the gatekeeper forwards the sanitized request to the appropriate backend service over a secure internal network. The gatekeeper adds metadata headers (validated client ID, authorization scope) so backend services can trust the request without re-validating. Communication between gatekeeper and backends often uses mutual TLS for additional security.

Step 6: Response Handling The backend service processes the request and returns a response to the gatekeeper. The gatekeeper may sanitize the response (strip sensitive headers, redact PII based on client permissions) before forwarding it to the client. Response times and status codes are logged for monitoring.

Step 7: Audit & Monitoring Every transaction through the gatekeeper generates audit logs with full request/response details, validation decisions, and timing information. These logs feed into SIEM systems for security analysis and compliance reporting. Anomalies trigger alerts to security teams.

Gatekeeper Request Validation Flow

graph LR
    Client["Client<br/><i>Web/Mobile App</i>"]
    GK["Gatekeeper<br/><i>Security Proxy</i>"]
    AuthSvc["Auth Service<br/><i>Token Validation</i>"]
    ThreatDB[("Threat Intel<br/><i>Blocklists</i>")]
    Backend["Backend Service<br/><i>Business Logic</i>"]
    AuditLog[("Audit Logs<br/><i>SIEM</i>")]
    
    Client --"1. POST /api/payment"--> GK
    GK --"2. Validate JWT"--> AuthSvc
    AuthSvc --"3. Token Valid"--> GK
    GK --"4. Check IP blocklist"--> ThreatDB
    ThreatDB --"5. IP Clean"--> GK
    GK --"6. Sanitize payload<br/>(strip XSS, validate schema)"--> GK
    GK --"7. Forward clean request<br/>+ metadata headers"--> Backend
    Backend --"8. Process & respond"--> GK
    GK --"9. Sanitized response"--> Client
    GK --"10. Log transaction"--> AuditLog

The gatekeeper validates every request through multiple security layers before forwarding to backend services. Each step (authentication, threat detection, sanitization) acts as a filter, ensuring only clean traffic reaches internal systems. All decisions are logged for audit trails.

Key Principles

Principle 1: Single Point of Entry All external traffic must flow through the gatekeeper—there should be no alternative paths to backend services. This is enforced through network segmentation (firewalls blocking direct access) and service configuration (backends only accept connections from gatekeeper IPs). Example: A financial services company places all customer-facing APIs behind a gatekeeper in a DMZ. Backend payment processing services run in a private VPC with security groups that only allow inbound traffic from the gatekeeper’s elastic IP addresses. Even internal developers must route through the gatekeeper for production access.

Principle 2: Fail Secure When the gatekeeper encounters ambiguous or edge-case requests, it defaults to rejection rather than permissive forwarding. Validation rules are explicit whitelists, not blacklists. If a request doesn’t match known-good patterns, it’s blocked. Example: Stripe’s API gatekeeper validates webhook signatures cryptographically. If a webhook arrives without a valid signature or with an expired timestamp, it’s rejected immediately—even if the payload looks legitimate. This prevents replay attacks and spoofed webhooks.

Principle 3: Defense in Depth The gatekeeper is one layer in a multi-layered security strategy, not a replacement for backend security. Backend services should still implement their own authentication, authorization, and input validation—the gatekeeper reduces attack surface but doesn’t eliminate the need for secure coding practices. Example: Netflix’s API gateway (Zuul) acts as a gatekeeper, but backend microservices still validate JWTs and enforce fine-grained permissions. If an attacker somehow bypasses Zuul (misconfiguration, internal threat), services don’t blindly trust incoming requests.

Principle 4: Minimal Privilege The gatekeeper runs with the minimum permissions necessary to perform its validation duties. It doesn’t have access to sensitive data stores or business logic—it only knows enough to make security decisions. This limits blast radius if the gatekeeper itself is compromised. Example: An e-commerce gatekeeper can query a user authentication service to validate tokens but has no access to the customer database, order history, or payment systems. It forwards validated requests to services that do have those permissions.

Principle 5: Auditability & Observability Every decision the gatekeeper makes must be logged with sufficient detail for forensic analysis and compliance audits. Logs include not just successful requests but also rejected attempts, validation failures, and rate limit triggers. These logs are immutable and stored in a separate security logging system. Example: A healthcare SaaS company’s gatekeeper logs every API call with client ID, requested resource, validation outcome, and response time. When auditors ask “Who accessed patient record X on date Y?”, the gatekeeper logs provide a complete audit trail showing the request came from authenticated user Z, passed all validation checks, and was forwarded to the EHR service.

Deep Dive

Types / Variants

Variant 1: Stateless Validation Gatekeeper This variant performs validation using only information in the request itself (tokens, signatures) without maintaining session state. It’s horizontally scalable because any gatekeeper instance can handle any request. Use when you need high throughput and can encode all necessary context in tokens. Pros: Simple to scale, no session synchronization, fast failover. Cons: Limited ability to detect sophisticated attacks that span multiple requests (credential stuffing, account takeover). Example: Auth0’s API gateway validates JWTs by checking signatures against public keys—no database lookups or session storage required. Each request is independently validated, allowing Auth0 to handle millions of requests per second across globally distributed gatekeeper instances.

Variant 2: Stateful Session-Aware Gatekeeper This variant maintains session state (active sessions, request history, rate limit counters) in a distributed cache like Redis. It can detect anomalies across multiple requests from the same client. Use when you need to enforce complex security policies like “max 3 failed login attempts per hour” or “flag users who suddenly change access patterns.” Pros: Sophisticated threat detection, behavioral analysis, accurate rate limiting. Cons: Requires state synchronization, more complex to scale, potential single point of failure if cache goes down. Example: Cloudflare’s Bot Management uses stateful gatekeepers that track client behavior across requests. If a client suddenly starts making requests 100x faster than their historical pattern, the gatekeeper flags it as potential bot activity—even if each individual request looks legitimate.

Variant 3: Inline Inspection Gatekeeper This variant performs deep packet inspection and content scanning, analyzing request payloads for malware, data exfiltration attempts, or policy violations. It may decrypt TLS traffic (using enterprise certificates) to inspect encrypted payloads. Use when you need to enforce data loss prevention (DLP) policies or scan for malicious content. Pros: Comprehensive threat detection, DLP enforcement, compliance with content policies. Cons: High latency overhead (payload scanning is slow), privacy concerns (decrypting TLS), complex certificate management. Example: Zscaler’s cloud security platform acts as an inline gatekeeper for enterprise traffic. It decrypts HTTPS connections, scans uploads for malware and sensitive data patterns (credit card numbers, SSNs), and blocks exfiltration attempts—all before traffic reaches SaaS applications.

Variant 4: Adaptive Gatekeeper with ML This variant uses machine learning models to detect anomalies and zero-day attacks based on behavioral patterns. It continuously learns normal traffic patterns and flags deviations. Use when you face sophisticated adversaries and need to detect novel attack vectors. Pros: Detects unknown threats, adapts to evolving attack patterns, reduces false positives over time. Cons: Requires significant ML infrastructure, potential for false positives during training, explainability challenges for compliance. Example: Darktrace’s network security uses ML-powered gatekeepers that learn the “pattern of life” for each user and device. When an employee’s account suddenly starts accessing unusual APIs or downloading large datasets at 3 AM, the gatekeeper flags it as potential account compromise—even if the credentials are valid.

Variant 5: Protocol-Specific Gatekeeper This variant is optimized for a specific protocol (HTTP/REST, gRPC, GraphQL, WebSocket) with deep understanding of protocol semantics. It can enforce protocol-specific security policies like GraphQL query depth limits or gRPC method-level authorization. Use when you have protocol-specific security requirements that generic proxies can’t enforce. Pros: Fine-grained protocol-aware policies, better performance than generic inspection, protocol-specific attack prevention. Cons: Requires separate gatekeepers for different protocols, more complex to maintain. Example: Apollo GraphQL’s gateway acts as a protocol-specific gatekeeper for GraphQL APIs. It enforces query complexity limits (preventing resource exhaustion attacks), validates operation names against a whitelist, and applies field-level authorization—security controls that only make sense in the GraphQL context.

Stateless vs Stateful Gatekeeper Comparison

graph TB
    subgraph Stateless Gatekeeper
        SL_Client["Client Request"]
        SL_GK["Gatekeeper<br/><i>No session state</i>"]
        SL_Validate["Validate JWT signature<br/>Check token expiry<br/>Parse claims"]
        SL_Forward["Forward to backend"]
        
        SL_Client --> SL_GK
        SL_GK --> SL_Validate
        SL_Validate --> SL_Forward
    end
    
    subgraph Stateful Gatekeeper
        SF_Client["Client Request"]
        SF_GK["Gatekeeper<br/><i>Session-aware</i>"]
        SF_Cache[("Redis<br/><i>Session store</i>")]
        SF_Check{"Check rate limit<br/>Analyze behavior<br/>Track failed attempts"}
        SF_Forward["Forward to backend"]
        SF_Block["Block request<br/><i>Anomaly detected</i>"]
        
        SF_Client --> SF_GK
        SF_GK --> SF_Cache
        SF_Cache --> SF_Check
        SF_Check --"Normal pattern"--> SF_Forward
        SF_Check --"Suspicious"--> SF_Block
    end
    
    Note1["✓ Scales horizontally<br/>✓ Fast (5-10ms)<br/>✓ Simple failover<br/>✗ Can't detect multi-request attacks"]
    Note2["✓ Sophisticated threat detection<br/>✓ Accurate rate limiting<br/>✓ Behavioral analysis<br/>✗ Requires state sync<br/>✗ Higher latency (20-50ms)"]
    
    SL_Forward -.-> Note1
    SF_Forward -.-> Note2

Stateless gatekeepers validate each request independently using only token information, enabling horizontal scaling but limiting attack detection. Stateful gatekeepers maintain session history in distributed caches, enabling sophisticated behavioral analysis at the cost of complexity and latency.

Trade-offs

Tradeoff 1: Security Depth vs. Latency Deeper inspection (payload scanning, ML analysis, DLP checks) provides better security but adds latency to every request. A simple token validation gatekeeper adds ~5-10ms, while deep packet inspection can add 50-200ms. Decision framework: For user-facing APIs where latency matters (mobile apps, real-time features), use lightweight stateless validation and push complex security checks to async background jobs. For batch APIs or admin interfaces where security trumps speed, use comprehensive inspection. Example: Uber’s rider app APIs use fast stateless gatekeepers (JWT validation only) to keep response times under 100ms, while their driver background check APIs use deep inspection gatekeepers that scan uploaded documents for fraud—latency is acceptable because it’s not user-facing.

Tradeoff 2: Centralized vs. Distributed Gatekeepers A single centralized gatekeeper simplifies policy management and provides a unified audit trail but creates a bottleneck and single point of failure. Distributed gatekeepers (one per region or service) improve performance and resilience but complicate policy synchronization. Decision framework: Use centralized for small-to-medium systems (<10K RPS) or when regulatory compliance requires a single audit point. Use distributed for global systems or high-throughput scenarios, with centralized policy management and log aggregation. Example: Stripe uses regional gatekeepers (one per AWS region) to minimize latency for international customers, but all gatekeepers pull policies from a centralized configuration service and ship logs to a unified security data lake.

Tradeoff 3: Inline vs. Out-of-Band Validation Inline validation (gatekeeper in the request path) provides immediate protection but adds latency and can become a bottleneck. Out-of-band validation (gatekeeper analyzes traffic asynchronously) doesn’t impact latency but can only react after potentially malicious requests reach backends. Decision framework: Use inline for authentication/authorization (must block before backend access) and critical input validation. Use out-of-band for behavioral analysis, anomaly detection, and forensics. Example: AWS WAF operates inline to block SQL injection attempts immediately, while AWS GuardDuty operates out-of-band to analyze CloudTrail logs for suspicious patterns—it can’t prevent the first malicious request but can block the attacker’s IP before they do significant damage.

Tradeoff 4: Stateless vs. Stateful Stateless gatekeepers scale horizontally without coordination but can’t detect multi-request attacks or enforce accurate rate limits. Stateful gatekeepers enable sophisticated policies but require distributed state management (cache, database) and are harder to scale. Decision framework: Start stateless for simplicity and scale. Add statefulness only when you need cross-request policies (rate limiting, session management, behavioral analysis). Use hybrid approaches: stateless for most requests, stateful for high-risk operations. Example: GitHub’s API uses stateless gatekeepers for read operations (GET requests) but stateful gatekeepers for write operations (POST/PUT/DELETE) to enforce rate limits like “max 5000 API calls per hour per token”—the stateful gatekeeper tracks usage in Redis.

Tradeoff 5: Generic vs. Application-Aware Generic gatekeepers (standard WAF, reverse proxy) are easy to deploy and maintain but can’t enforce application-specific security policies. Application-aware gatekeepers understand your business logic and can enforce rules like “users can’t transfer more than their account balance” but require custom development. Decision framework: Use generic gatekeepers for commodity security (auth, input validation, DDoS protection). Build application-aware gatekeepers only for business-critical security rules that can’t be expressed generically. Example: PayPal uses generic gatekeepers (Akamai WAF) for standard web attacks but built custom application-aware gatekeepers that understand payment flows—they can detect and block suspicious transaction patterns like “user suddenly sending money to 50 new recipients” which looks normal to a generic WAF.

Security Depth vs Latency Tradeoff

graph LR
    Request["Client Request"]
    
    subgraph Lightweight - 5-10ms
        L1["JWT Validation<br/><i>Signature check</i>"]
        L2["Basic Schema<br/><i>Type validation</i>"]
        L_Backend["Backend<br/><i>95ms total latency</i>"]
    end
    
    subgraph Medium - 20-50ms
        M1["JWT + OAuth<br/><i>Token introspection</i>"]
        M2["Schema + Sanitization<br/><i>Strip XSS/SQL injection</i>"]
        M3["Rate Limiting<br/><i>Redis lookup</i>"]
        M_Backend["Backend<br/><i>120ms total latency</i>"]
    end
    
    subgraph Deep - 50-200ms
        D1["Full Auth Chain<br/><i>Multi-factor checks</i>"]
        D2["Deep Payload Scan<br/><i>Malware detection</i>"]
        D3["ML Anomaly Detection<br/><i>Behavioral analysis</i>"]
        D4["DLP Scanning<br/><i>PII/sensitive data</i>"]
        D_Backend["Backend<br/><i>250ms total latency</i>"]
    end
    
    Request --> L1 --> L2 --> L_Backend
    Request --> M1 --> M2 --> M3 --> M_Backend
    Request --> D1 --> D2 --> D3 --> D4 --> D_Backend
    
    UseCase1["Use for:<br/>User-facing APIs<br/>Mobile apps<br/>Real-time features"]
    UseCase2["Use for:<br/>Standard web APIs<br/>Internal services<br/>Moderate security needs"]
    UseCase3["Use for:<br/>Admin interfaces<br/>Financial transactions<br/>Compliance-critical ops"]
    
    L_Backend -.-> UseCase1
    M_Backend -.-> UseCase2
    D_Backend -.-> UseCase3

Deeper security inspection provides better protection but adds significant latency. Choose validation depth based on use case: lightweight for latency-sensitive user-facing APIs, deep inspection for compliance-critical operations where security trumps speed.

Common Pitfalls

Pitfall 1: Gatekeeper Becomes a Single Point of Failure Teams deploy a gatekeeper for security but don’t properly handle its failure scenarios. If the gatekeeper goes down and there’s no failover, the entire system becomes unavailable. Why it happens: Security teams focus on threat prevention but neglect availability requirements. They deploy a single gatekeeper instance or don’t test failover procedures. How to avoid: Deploy gatekeepers in high-availability configurations (multiple instances behind a load balancer, health checks, automatic failover). Have a documented incident response plan for gatekeeper failures. Consider a “fail open” mode for non-critical systems where the gatekeeper can be bypassed during outages (with appropriate logging and alerts). Example: A fintech startup deployed a single gatekeeper instance to save costs. When it crashed during peak trading hours, their entire platform went offline for 45 minutes—costing them customer trust and regulatory scrutiny. They rebuilt with three gatekeeper instances across availability zones with automatic failover.

Pitfall 2: Validation Logic Drift Between Gatekeeper and Backends The gatekeeper validates requests using one set of rules, but backend services use different validation logic. Attackers exploit these inconsistencies by crafting requests that pass gatekeeper validation but trigger vulnerabilities in backends. Why it happens: Gatekeeper and backend teams work independently, validation rules aren’t centrally managed, or backends are updated without updating gatekeeper rules. How to avoid: Use schema-driven validation where both gatekeeper and backends validate against the same OpenAPI/Protobuf schemas. Implement integration tests that verify gatekeeper and backend validation consistency. Centralize validation rule management in a policy engine that both layers consume. Example: A SaaS company’s gatekeeper validated email addresses with a simple regex, but the backend user service used a more permissive parser. Attackers sent emails with special characters that passed gatekeeper validation but caused SQL injection in the backend. They fixed it by moving to a shared validation library used by both layers.

Pitfall 3: Over-Trusting Gatekeeper-Validated Requests Backend services assume that any request from the gatekeeper is fully validated and safe, so they skip their own security checks. If the gatekeeper is misconfigured or compromised, backends are completely exposed. Why it happens: Defense-in-depth is sacrificed for performance or developer convenience. Teams think “the gatekeeper handles security, so we don’t need to validate in backends.” How to avoid: Always implement security checks in backend services even if they duplicate gatekeeper logic. Use the gatekeeper as a first line of defense, not the only line. Treat internal traffic as potentially malicious (zero-trust principle). Example: Uber’s internal services validate authentication tokens even though requests come through their API gateway (gatekeeper). When a misconfigured gateway accidentally forwarded unauthenticated requests, backend services still rejected them—preventing a major security incident.

Pitfall 4: Logging Sensitive Data in Gatekeeper Logs Gatekeepers log request/response details for audit trails, but developers accidentally log sensitive data (passwords, credit cards, PII) in plaintext. These logs become a security liability and compliance violation. Why it happens: Logging is configured to capture full request bodies for debugging, and teams don’t sanitize sensitive fields. Developers don’t realize logs are stored long-term and accessible to many people. How to avoid: Implement automatic redaction of sensitive fields (passwords, tokens, credit cards) in logs. Use structured logging with explicit field-level controls. Regularly audit logs for sensitive data leakage. Encrypt logs at rest and restrict access. Example: A healthcare company’s gatekeeper logged full request bodies including patient SSNs and medical records. During a compliance audit, they discovered logs were stored unencrypted in S3 with overly broad access permissions. They implemented field-level redaction and encrypted log storage to achieve HIPAA compliance.

Pitfall 5: Performance Degradation Under Attack The gatekeeper becomes a bottleneck during DDoS attacks or traffic spikes because validation is CPU-intensive. Ironically, the security layer causes availability problems. Why it happens: Gatekeepers are sized for normal traffic, not attack scenarios. Complex validation rules (regex, payload parsing) consume significant CPU. Rate limiting isn’t aggressive enough to shed malicious load. How to avoid: Load test gatekeepers under attack scenarios (10x-100x normal traffic). Implement aggressive rate limiting and circuit breakers that shed load before the gatekeeper is overwhelmed. Use efficient validation algorithms (compiled regex, streaming parsers). Consider offloading DDoS protection to a CDN/WAF provider (Cloudflare, Akamai) before traffic reaches your gatekeeper. Example: A gaming company’s gatekeeper used complex regex patterns to validate usernames. During a DDoS attack with millions of malicious registration attempts, the regex engine consumed 100% CPU and the gatekeeper crashed. They switched to simpler validation rules and added Cloudflare’s DDoS protection in front of their gatekeeper.

Validation Logic Drift Attack Vector

sequenceDiagram
    participant Attacker
    participant Gatekeeper
    participant Backend
    participant Database
    
    Note over Gatekeeper: Validates email with<br/>simple regex: ^[a-z@.]+$
    Note over Backend: Parses email with<br/>permissive library
    
    Attacker->>Gatekeeper: POST /register<br/>email: "user@evil.com'--"
    Gatekeeper->>Gatekeeper: Regex validation PASS<br/>(contains only a-z@.'-)
    Gatekeeper->>Backend: Forward validated request
    Backend->>Backend: Parse email with library<br/>Extracts: user@evil.com'--
    Backend->>Database: INSERT INTO users<br/>VALUES ('user@evil.com'--')
    Note over Database: SQL injection!<br/>Comment truncates query
    Database-->>Backend: Malicious query executed
    Backend-->>Gatekeeper: 200 OK
    Gatekeeper-->>Attacker: Account created
    
    Note over Gatekeeper,Backend: ❌ Pitfall: Different validation logic<br/>between gatekeeper and backend<br/><br/>✓ Solution: Use shared validation library<br/>or schema-driven validation

When gatekeeper and backend use different validation logic, attackers can craft payloads that pass gatekeeper checks but exploit backend vulnerabilities. This example shows SQL injection via email field where the gatekeeper’s regex allows special characters that the backend’s SQL query doesn’t properly escape. Always use consistent validation across all layers.

Math & Calculations

Capacity Planning for Gatekeeper Throughput

Formula: Max Throughput (RPS) = (CPU Cores × CPU Efficiency) / Avg Request Processing Time

Variables:

  • CPU Cores: Number of cores available to gatekeeper instances
  • CPU Efficiency: Percentage of CPU time spent on useful work (typically 0.7-0.8 accounting for context switching)
  • Avg Request Processing Time: Time to validate one request (measured in seconds)

Worked Example: You’re designing a gatekeeper for an API that expects 50,000 requests per second at peak. Each request requires:

  • JWT validation: 0.5ms (cryptographic signature verification)
  • Schema validation: 0.3ms (JSON parsing and validation)
  • Rate limit check: 0.2ms (Redis lookup)
  • Total: 1ms per request

Calculation:

  • Target throughput: 50,000 RPS
  • Per-core throughput: 1 core × 0.75 efficiency / 0.001s = 750 RPS per core
  • Required cores: 50,000 / 750 = 67 cores
  • With 16-core instances: 67 / 16 = 5 instances minimum
  • Add 50% headroom for spikes: 5 × 1.5 = 8 instances
  • Deploy across 3 AZs: 9 instances (3 per AZ)

Cost implications: At $0.50/hour per 16-core instance, this costs $3,240/month. If you can optimize validation to 0.5ms per request (caching validation results, using faster crypto libraries), you’d only need 4 instances, saving $1,800/month.

Latency Budget Analysis

Formula: P99 End-to-End Latency = P99 Network + P99 Gatekeeper + P99 Backend + P99 Network

Worked Example: Your SLA promises 200ms P99 latency for API responses. Measurements show:

  • P99 network latency (client to gatekeeper): 30ms
  • P99 backend processing: 80ms
  • P99 network latency (gatekeeper to backend): 5ms
  • P99 network latency (backend to client): 30ms

Available gatekeeper budget: 200ms - 30ms - 80ms - 5ms - 30ms = 55ms

If your gatekeeper validation takes 60ms at P99, you’re violating SLA. Options:

  1. Optimize validation to <55ms (cache validation results, use faster algorithms)
  2. Negotiate a higher SLA (250ms instead of 200ms)
  3. Reduce backend latency to create more gatekeeper budget

This math shows why lightweight stateless validation is preferred for latency-sensitive APIs—complex validation can easily consume your entire latency budget.