What concrete costs does adding a Gatekeeper host in front of a backend service impose, and what do you get in return for paying them?

## Both sides of the ledger Every architectural pattern is a trade of one kind of cost for another kind of risk reduction, and **Gatekeeper** is a particularly clean example because both sides of the ledger are concrete and measurable rather than vague. Understanding the trade honestly — not just reciting 'better security' — is what separates someone who's memorized the pattern from someone who can decide when to apply it. ## The costs Start with the costs, because they're the ones a team feels immediately. 1. **First, latency:** a request that used to go client → backend now goes client → gatekeeper → (possibly a queue) → trusted host → backend, adding at least one extra network hop and, if the inter-tier channel is asynchronous, potentially real queuing delay. For latency-sensitive paths (a checkout flow, a live search), this is not free, and if the trusted-host hop is implemented as a poll-based queue consumer, delay can range from milliseconds to seconds depending on polling interval — a detail that matters a great deal for user-facing synchronous flows and often forces designs into either fast-poll queues, push notifications from queue to consumer, or accepting the pattern is better suited to write-heavy/async operations than low-latency reads. 2. **Second, operational surface:** you're now running, monitoring, alerting on, and patching two classes of infrastructure instead of one — the gatekeeper fleet and the trusted host — plus, in the common queue-based implementation, the queue itself as a third moving part with its own failure modes (message loss, poison messages, ordering guarantees). Each of those needs its own on-call runbook, its own capacity planning, its own upgrade cadence. For a small team, this is a real tax, not a rounding error — it can easily double the deployable-unit count for a single logical service. 3. **Third, validation drift:** the gatekeeper's checks (schema, allowed fields, size limits, character sanitization) are a second copy of a contract that also lives, implicitly or explicitly, on the backend/trusted host. Contracts drift. A backend team ships a new field or loosens a constraint and forgets the gatekeeper needs updating too — now legitimate traffic bounces off the gatekeeper (a functional bug, showing up as elevated 4xx rates) or, in the more dangerous direction, the gatekeeper's checks become stale relative to a newly-vulnerable input path the backend added, meaning the gatekeeper isn't actually filtering the thing that matters anymore. This isn't hypothetical — it's the standard failure mode of any system where the same contract is enforced redundantly in two places that don't share a single source of truth. 4. **Fourth, a load-bearing component:** the gatekeeper itself becomes a capacity-planning and availability concern it wasn't before: because all legitimate traffic now funnels through it, an under-provisioned or buggy gatekeeper fleet can take an otherwise perfectly healthy backend offline from the outside — you've added a load-bearing component to every request path. ## The benefit side Now the benefit side, which is what justifies eating those costs in the right scenario. - **The headline win is blast-radius reduction:** the component reachable by untrusted clients holds no valuable long-lived secrets, so a full remote-code-execution compromise of it — the worst case for any internet-facing service — doesn't hand the attacker the database. That's a categorically different outcome from a monolithic backend where the same RCE is game over. - **A secondary win is operational hygiene** forced by the pattern's own design: because the gatekeeper is meant to be minimal and disposable, teams following the pattern tend to rebuild it from clean images regularly, which incidentally also clears out any low-and-slow persistence an attacker achieved, something that rarely happens naturally on a long-lived monolithic backend. ## When the trade is worth it So when is the trade worth it? The deciding variable is usually the **sensitivity of what's behind the backend** crossed with **how untrusted the client population is**. A public API accepting file uploads from anonymous internet users, writing into a database that also serves paying customers' financial records, is a strong candidate — the cost of the extra hop and infrastructure is small next to the cost of a full data breach. ## When it does not earn its keep Conversely, an internal service called only by other services inside a locked-down VPC, already behind mTLS and a service mesh's authorization policy, gets much less marginal benefit from adding a Gatekeeper tier — the client population isn't meaningfully untrusted in the way the pattern is designed to defend against, and the same isolation goal may already be achieved more cheaply via mesh-level policy and least-privilege service identities. Recognizing that second case — where the pattern's cost isn't earning its keep — is exactly the judgment interviewers are probing for when they ask 'when would you NOT use this.'