Think of a high-security building where the receptionist in the lobby can check your ID, search your bag, and call ahead — but can't actually open the vault. Even if someone tricks or overpowers the receptionist, they've gained nothing useful: the keys and the valuables live somewhere the lobby simply can't reach.
The Gatekeeper pattern builds exactly that arrangement for your services. A locked-down public-facing instance receives every request, inspects it, and forwards only the clean ones inward — while the systems that actually hold your data stay tucked away where the internet can't see them.
The problem
Any service exposed to the public internet is under constant attack — malformed payloads, injection attempts, probes for known exploits. If that same service also holds your database credentials, decryption keys, and direct access to storage, then a single successful exploit is catastrophic. The attacker doesn't just crash a process; they walk straight into your most valuable data.
Piling validation, throttling, and business logic all into one exposed process makes the attack surface enormous. Every line of code that touches a secret is now reachable from the open internet. You want the part that faces hostile traffic to be as small, dumb, and disposable as possible.
Exposed hostFaces the open internet AND holds the database credentials and decryption keys. Every line that touches a secret is reachable by an attacker.
Data + credentialsDirectly reachable from the exposed process, so a single successful exploit walks straight into your most valuable data.
How it works
The Gatekeeper pattern splits the system into two tiers. The gatekeeper is a dedicated instance sitting at the edge whose only job is to validate and sanitize: it checks the request format, strips dangerous input, enforces basic rules, and rejects anything suspicious outright. Crucially, it holds no secrets and has no direct line to storage or the database.
Behind it, in a private network the public can't reach, sit the trusted hosts that do the real work and hold the real credentials. They accept connections only from the gatekeeper. So if the exposed instance is ever compromised, the attacker is stuck in a process with nothing worth stealing and no path inward except the same narrow, validated channel everyone else uses. The diagram below shows a request passing through the gatekeeper before it's allowed to reach the protected service and its data.
- GatekeeperExposed to the internet but holds no secrets and can't reach storage directly — it only validates and sanitizes.
- Trusted hostLives in a private network, accepts connections only from the gatekeeper, and holds the real credentials.
- Secured dataReachable only through the trusted tier — compromising the edge gives an attacker no path here.
Keep the gatekeeper dumb on purpose. The less logic and the fewer secrets it carries, the less an attacker gains by breaking it. Resist the temptation to let business rules or cached credentials creep into the edge tier — that erosion quietly turns your gatekeeper back into the fat, exposed service it was meant to replace.
When to use it
Reach for a gatekeeper when the data or actions behind your service are genuinely sensitive — payment systems, health records, anything where a breach is a headline. It pairs naturally with an API gateway: the gateway routes and aggregates, while the gatekeeper's distinct concern is shrinking the blast radius of an attack. You can even let the gatekeeper handle offloading concerns like input sanitization at the same edge.
It's not free — you're running an extra tier and adding a hop to every request. For a low-stakes internal tool, that overhead buys little. But for the systems where being wrong is expensive, splitting the exposed-but-dumb part from the smart-but-protected part is one of the cheapest large wins in security architecture.