Gatekeeper Pattern
The gatekeeper pattern places a single, hardened gateway between clients and backend services. The gateway validates requests (authentication, authorization, schema, rate limits), rejects invalid ones, and forwards only clean traffic to the backends. Backends trust the gateway and don't repeat the checks. This concentrates security in one well-audited place rather than spreading it (inconsistently) across every service.
Foundational.
How it works
The gatekeeper is a reverse proxy that sits in front of backend services and acts as the single entry point. It handles cross-cutting concerns so backends don't have to:
- Authentication: verify the caller's identity (API key, JWT, OAuth token).
- Authorization: check the caller has permission for this request (scopes, roles).
- Rate limiting: enforce per-client limits; reject with 429.
- Schema validation: reject malformed requests before they reach the backend.
- TLS termination: decrypt HTTPS at the edge; backends receive plain HTTP (or mTLS in a service mesh).
- Request sanitization: strip sensitive headers, normalize inputs.
- Logging and metrics: emit access logs, latency metrics, error rates.
The backend trusts the gateway: if a request arrives, it's been authenticated, authorized, and validated. The backend focuses on business logic, not security plumbing.
This pattern is also called an API gateway when it adds protocol translation, request composition, and other API-management features.
The gatekeeper establishes a trust boundary. Inside the boundary (between gateway and backends), traffic is trusted — backends accept requests without re-validating auth. Outside the boundary (between client and gateway), nothing is trusted.
This implies two things:
-
The network between gateway and backends must be secured (private VPC, mTLS, network policies). If any attacker can reach a backend directly, bypassing the gateway, the pattern fails. The backends trust all traffic from inside the boundary.
-
The gateway must be thorough. If it misses a check, the backend won't catch it. Common gaps: not validating request bodies, not checking scopes on every route, rate-limiting only some endpoints. The gateway's correctness is the system's correctness.
For defense in depth, some backends do partial re-validation ("defense in depth") — but the gateway is the primary check. The backend's check is a safety net, not the main control.
Gatekeeper vs API Gateway: the terms overlap. A gatekeeper is the security-focused reverse proxy. An API Gateway is a broader role: it adds API management features (protocol translation, request composition, response caching, developer portal, monetization).
In practice, most modern API gateways (Kong, AWS API Gateway, Apigee) do both: gatekeeper security + API management. The gatekeeper pattern is the security subset of the API Gateway role.
A service mesh (Istio, Linkerd) extends the pattern to service-to-service calls: every service has a sidecar that acts as a gatekeeper for inbound traffic and as an authenticated client for outbound traffic. The mesh provides mTLS, authorization policies, and telemetry across every hop — not just at the edge.
Concentrating security in the gateway means concentrating failure there too. If the gateway is down, no one can reach the backends. Mitigations: run multiple gateway instances behind a load balancer; design stateless gateways so any instance can serve any request; have health checks that remove failing instances. The gateway must also be highly available — it's now part of the critical path. Don't make the gateway stateful (per-client rate limit state needs shared storage like Redis, not local memory). The pattern's benefits far outweigh the SPOF risk if architected correctly.
Beyond security, gateways typically provide:
- Routing: route /api/v1/orders to the orders service, /api/v1/users to the users service.
- Versioning: support multiple API versions simultaneously.
- Request composition: combine responses from multiple backends into one response (rare; usually better done in a BFF).
- Response caching: cache idempotent GETs at the gateway.
- Protocol translation: accept HTTP/REST from clients, call gRPC to backends.
- Quotas and billing: track per-customer usage for monetized APIs.
These features make the gateway an API management tool, not just a security tool. AWS API Gateway, Kong, Apigee, and Envoy + Gloo are the main players.
The trade-off: every feature added to the gateway is a feature not implemented in backends (good) but also a feature the gateway must scale to handle (potentially limiting). Keep the gateway fast and focused; push business logic to backends.
Why is it a problem if backends can be reached directly, bypassing the gateway?
Pick one answer.
What cross-cutting concerns does a gatekeeper typically handle? (Select the best set.)
Pick one answer.
Why must the gateway be stateless (or use shared state) for high availability?
Pick one answer.
Engineering mental model
Mental model. Think of Gatekeeper Pattern as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Gatekeeper Pattern mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Gatekeeper Pattern, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = gatekeeper(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Gatekeeper Pattern
Change the variables below and predict what breaks first in Gatekeeper Pattern. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Gatekeeper Pattern, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Gatekeeper Pattern. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Gatekeeper Pattern?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Gatekeeper Pattern, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Gatekeeper Pattern, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
For Gatekeeper Pattern, define the trust boundary first. Identify who is allowed to perform each action, where credentials live, how they expire, and what a compromised credential can reach.
Numerical sanity check
A practical blast-radius question: if one credential is compromised, how many users, services, records or regions could it affect? Prefer designs where that number is deliberately bounded.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
What is the smallest trust boundary you would enforce for Gatekeeper Pattern, and what would you log so a suspicious action can be investigated later?
Pick one answer.
What you gain, what you pay
- +Centralizes cross-cutting security concerns in one well-audited place.
- +Backends focus on business logic, not security plumbing.
- +Single point for logging, metrics, and policy enforcement.
- +Standard pattern with mature tooling (Kong, AWS API Gateway, Envoy).
- −Single point of failure — must be highly available.
- −Adds a network hop (latency).
- −Backends trust the boundary — direct access bypasses all checks.
- −Can become a bottleneck if it grows too many features.
How this breaks in production
- Backend reachable directly, bypassing the gateway (boundary not enforced).
- Gateway becomes a single point of failure (no HA).
- Stateful gateway loses rate limit state on instance failure.
- Gateway becomes a monolith — too much business logic in the wrong layer.
Don't fall into these traps
- •Letting backends be reachable from outside the gateway boundary.
- •Putting business logic in the gateway instead of backends.
- •Running a single gateway instance (no HA).
- •Forgetting that backends trust the gateway — defense in depth is still wise.
Real systems using this
How real systems implement this
- AWS API Gateway — Managed gateway handling auth (Cognito, Lambda authorizers), rate limiting, request validation, TLS termination, and routing to backends. Backends run in private subnets reachable only through the gateway.
- Istio service mesh — Extends the gatekeeper pattern to service-to-service calls. Every service has an Envoy sidecar that enforces mTLS, authorization policies, and telemetry. The mesh becomes a distributed gatekeeper covering every hop.
Practice saying it out loud
- Q1What is the gatekeeper pattern, and what concerns does it centralize?
- Q2Why must backends not be reachable directly, bypassing the gateway?
- Q3How does the gatekeeper pattern differ from a service mesh?
- Q4How do you make the gateway highly available without losing per-client rate-limit state?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Gateway Routing