In the Gatekeeper cloud design pattern, what does the dedicated gatekeeper host do to a client's request before it reaches a backend service, and why does it run separately from that backend?
answer
- sacrificial front-door host
- validate & sanitize before forward
- minimal privileges by design
- separate from backend credentials
- reduces blast radius
basics
~10 sA gatekeeper is a stripped-down front-door server that checks and cleans every incoming request before it's allowed through, so bad or malformed input never touches the real backend systems directly.
solid answer
~40 sThe Gatekeeper pattern places a minimal, hardened proxy between untrusted clients and backend services. Every request first hits the gatekeeper, which validates schema, size, auth tokens, and sanitizes input, rejecting anything malformed or suspicious. Only after validation does it forward a normalized request onward, often to a separate internal trusted host that actually holds credentials to databases/storage/queues. The gatekeeper itself is deliberately kept minimal — as little code, as few dependencies, as few privileges as possible — and runs on isolated infrastructure. Its point is not general request routing but risk containment: because it's the piece attackers can reach directly, it's built to be expendable. If compromised, it shouldn't have direct database credentials or the ability to reach sensitive resources, limiting blast radius compared to exposing the backend directly.
go deeper
Should describe, in plain terms, that a special front-line host checks requests before anything reaches the backend, and that this host is not the same as the backend itself.
Should explain WHY it's separated (privilege/blast-radius reasoning), not just that it is, and mention that the gatekeeper is deliberately kept minimal/disposable.
Should discuss the two-tier gatekeeper/trusted-host split, the restricted channel between them, and concrete failure modes like privilege leakage or validation drift.
Should weigh this against alternatives (WAF, API gateway, service mesh mTLS) and articulate when the isolation cost is and isn't justified for a given threat model.
## The question it answers The Gatekeeper pattern addresses a simple but consequential question: when a client — especially an untrusted or lightly-trusted one, such as a public internet caller or a third-party integration — needs to reach a backend system that holds sensitive data or credentials, should that client's request ever touch the backend directly? **The pattern's answer is no.** Instead, every inbound request is routed first to a dedicated, deliberately minimal host called the **gatekeeper**. Its only job is to: - **validate the request's shape** — schema, field types, size limits; - **check** authentication/authorization tokens; - **sanitize input** against injection-style payloads; - and **reject** anything that fails those checks outright. Only requests that pass are forwarded onward — typically not straight to the backend either, but to a second, internal 'trusted host' that actually holds the credentials and does the real work (this two-tier split is covered in more depth elsewhere, but even a single-tier gatekeeper embodies the core idea). ## How the host is built Mechanically, the gatekeeper is built to be as small and boring as possible: - minimal OS image; - few installed packages; - no unnecessary services; - and critically, no direct credentials to the backend's data stores. It typically sits in a network segment (e.g., a DMZ or public subnet) that clients can reach, while the backend sits in a separate, more restricted segment the gatekeeper — not the client — is permitted to reach, and even then only through a narrow, well-defined channel. ## Why it exists Why does this exist? The core problem is **attack-surface concentration**. Any component that's reachable by an untrusted client is, by definition, the piece an attacker will probe first — for buffer overflows, injection, auth bypass, deserialization bugs, whatever the vulnerability class of the week is. If that reachable component is the same one holding database passwords, storage account keys, or admin APIs, then a single successful exploit against it is a full backend compromise. The Gatekeeper pattern breaks that coupling: the reachable component is intentionally 'sacrificial' — cheap to rebuild, holding no valuable secrets, and running enough logic to filter obvious garbage but not enough logic to be a rich target itself. Even if an attacker fully compromises the gatekeeper, the blast radius is capped at whatever narrow capability the gatekeeper itself was granted, not full backend access. ## The trade-off The trade-offs run in both directions. On the cost side: - every legitimate request now takes an extra network hop, adding **latency**; - you now operate and patch two classes of infrastructure instead of one; - and validation logic can drift out of sync between what the gatekeeper checks and what the backend actually expects, creating either **false rejections** (gatekeeper is stricter than backend, breaking valid use cases) or, worse, **false acceptances** (gatekeeper misses something the backend is vulnerable to). On the benefit side: - a compromised gatekeeper doesn't hand over the keys to the kingdom; - and the backend's attack surface toward the open internet effectively drops to zero, since the only party allowed to talk to it is the gatekeeper (or the internal trusted host) over an internal, restricted channel. ## Failure modes Failure modes show up in a few recognizable shapes. 1. **First, an under-scaled gatekeeper fleet** becomes a throughput bottleneck or a single point of failure — since all traffic funnels through it, a traffic spike or a bug that exhausts its connection pool can take down access to an otherwise-healthy backend. 2. **Second, 'privilege leakage':** teams under deadline pressure sometimes give the gatekeeper more than the minimum it needs (e.g., direct database credentials 'just to keep things simple'), which quietly defeats the pattern's whole purpose — a compromise of the gatekeeper is now a compromise of everything. 3. **Third, validation drift**, where the gatekeeper's sanitization rules go stale relative to a backend that has evolved its accepted input formats, producing subtle correctness bugs or security gaps that are hard to spot because two components now need to agree on one contract. ## Where it shows up A concrete real-world shape of this pattern: Microsoft's Azure Architecture Center documents Gatekeeper as a reference pattern for scenarios like a public web app that needs to write to Azure Storage or a database on behalf of untrusted users. A fleet of small, load-balanced gatekeeper VMs (or lightweight services) does authentication and payload validation, then hands off validated requests via an internal queue to a separate trusted-host tier that holds the actual storage/database credentials and performs the write. The gatekeeper VMs can be rebuilt from a minimal, hardened image on every deploy, so even a successful RCE against one buys an attacker almost nothing of lasting value.
- Does the gatekeeper need to be smart — running lots of business logic — to do its job well?No, and intentionally not: the more logic and dependencies you add, the bigger the gatekeeper's own attack surface becomes, defeating the purpose. It should carry only validation, sanitization, and auth-check logic, and stay as close to a minimal, disposable image as feasible. Business logic belongs on the trusted, non-internet-facing side.
- How does a gatekeeper differ from a plain reverse proxy or load balancer sitting in front of an API?A plain reverse proxy typically focuses on routing, TLS termination, and load distribution, and is often trusted with the same network reach as the backend. A gatekeeper is defined by privilege isolation — it deliberately holds no backend credentials and is treated as expendable, so its compromise doesn't equal backend compromise, which isn't guaranteed by a generic proxy.
- What happens if the gatekeeper rejects a request — does the client get useful feedback?Typically yes, with generic, non-revealing error responses (e.g., a 400) — but they must be carefully worded to avoid leaking internal validation rules or stack traces that would help an attacker fingerprint the gatekeeper's exact checks.
Like a building's reception desk that checks your ID and bag before letting you past the lobby — the receptionist never holds keys to the server room, so even a fake visitor who fools reception still can't get past the next locked door.
saying these in an interview costs you the question
- Says the gatekeeper holds the backend database credentials for convenience
- Can't explain why the gatekeeper is kept minimal rather than feature-rich
- Confuses the gatekeeper with generic load balancing/routing with no privilege distinction
- Doesn't mention validating/sanitizing input as the core responsibility
- Assumes the gatekeeper replaces the need for backend-side validation entirely