Edge: The Request Pipeline

A request that should be rejected costs you nothing. That is the point of the ordering below: by the time anything reaches your service, it has been routed, rate limited, authenticated, authorised, metered, budget-checked and validated — and every one of those can end the request before your backend is called.

The gateway is not a proxy with policies attached. It is an ordered pipeline of stages, and the order is the design.

What Happens Before Your Service Is Called

A request is routed to its operation, rate limited, authenticated, authorised, metered, checked against budget, and validated — and any one of those can end it. Only then is your service called.

The ordering is deliberate rather than incidental, and three properties follow from it.

Three Properties Worth Knowing

Everything that can reject runs before stage 14. Rate limits, authorisation, resource units, budget guards and dependency pre-flight all complete before your service sees a request. A caller who is over quota, out of budget, unauthenticated or unauthorised never costs you an upstream call — which matters most for the operations that aggregate, where one inbound request would otherwise fan out into several expensive ones.

Rate limiting precedes authentication. Verifying a credential is more expensive than counting a request, so a caller hammering an endpoint is rejected on the cheap check rather than the costly one.

Protection runs after authentication, not before. Payload scanning happens once the caller is known, so every event is attributable to an identity rather than to a source address — which is what makes the resulting security events worth having. Unauthenticated traffic is rejected at the security stage and never enters inspection at all. See Protection for what it checks and why it is not a firewall.

Metering sits between security and forwarding. Consumption is recorded against a known subscription, and an over-consumption decision is taken before the backend is involved rather than after it has already done the work.

Note

Where this runs is a deployment decision. On PaaS it runs in our infrastructure and sees your inbound traffic. As a micro-gateway inside your own cluster it also sees service-to-service calls, so internal traffic is subject to exactly the same enforcement. See Deployment Models.

What It Produces

Enforcement is not the only output. The same pass emits the record everything else is built from: security events feed Risk Management, metering feeds Wealth Engine and cost control, and the compliance stages produce the evidence used for NIS2, DORA and the EU AI Act. The audit trail is a by-product of serving the request, not a separate logging exercise.

See also: Security · Risk Management · Metering · Deployment Models