An API gateway often arrives with a rather attractive promise: a common entry point through which clients can access our services, while authentication, routing, rate limits, and other shared policies are handled centrally.
Quite understandably, this leads to a question:
“If the gateway already validates incoming requests, what should the services behind it still validate?”
Well, the answer depends upon what we mean by validation. Checking whether a request carries a valid token and determining whether that request should be allowed to cancel a particular booking are two very different responsibilities.
Let’s explore where the gateway’s responsibility ends and where the service’s responsibility begins.
Understanding the Gateway’s Role
Imagine an application that exposes services for searching products, managing customer profiles, and processing orders.
Without a common gateway, each service might require its own externally accessible endpoint and independently managed policies. An API gateway provides a place to consolidate shared concerns such as routing, authentication, traffic controls, and API access policies. Microsoft’s API Management documentation describes controls for both client-to-gateway and gateway-to-backend communication.
This is useful centralization. A service should not need to know which public hostname a customer used to reach it, or how the enterprise distributes incoming traffic across its environments.
However, centralizing access to services does not automatically centralize every decision those services must make.
A Valid Token Is Only the Beginning
Consider a request to cancel an order:
POST /orders/12345/cancel
Suppose the gateway establishes that the caller’s token is valid and carries an appropriate permission for order cancellation.
Can we now cancel order 12345?
We still need answers to several questions:
Does this order belong to the customer making the request?
If an employee is acting on the customer’s behalf, are they authorized to do so?
Has the order already been dispatched?
Has it already been cancelled?
Does its current state permit cancellation?
These questions depend on the order, the caller’s relationship to it, and the business rules governing the operation.
My recommendation is to keep these decisions within the service that owns the order. Moving them into gateway policies would make the gateway dependent on business data and lifecycle rules that the order service already understands.
The distinction is useful: permission to invoke an operation does not establish permission to perform that operation on every resource.
There Are Several Kinds of Validation
The word validation tends to hide a surprising amount of architectural detail.
For a request entering our system, I find it useful to separate the following concerns:
| Concern | Example | Suggested ownership |
|---|---|---|
| Traffic policy | Is the caller exceeding an allowed request rate? | Gateway |
| Identity verification | Is the presented credential valid for its intended use? | Explicitly designed authentication boundary |
| Request structure | Is a required field missing or incorrectly formatted? | Service, with optional gateway screening |
| Resource authorization | May this caller modify this particular order? | Service owning the resource |
| Business rules | Can an order in this state be cancelled? | Service owning the operation |
This is a starting point for assigning responsibilities, rather than a prescription for a particular product.
For example, a gateway may reject a malformed request before it consumes backend resources. That is useful. The service should still enforce the input contract on which its own behavior depends.
Should Every Service Validate the Token Again?
Here, it is tempting to prescribe a universal rule: every service must repeat every authentication check.
I would first ask how identity and trust travel through the system.
One design forwards an access token to a backend that validates it for the intended audience. Another authenticates the caller at the gateway and passes identity through a protected internal mechanism.
Microsoft’s microservices guidance discusses centralized authentication at a gateway and separately addresses authentication when services can be accessed directly. The available access paths therefore matter to the design.
Whichever approach we choose, we should be able to answer:
How does the receiving service establish that the identity accompanying this request is trustworthy?
An identity header, by itself, does not answer that question.
Suppose a service accepts X-User-Id as evidence of the caller’s identity. If a client can reach that service directly and supply the same header, the service has no reliable basis for distinguishing a trusted assertion from a caller’s invention.
A design using forwarded identity must protect the backend connection, authenticate the trusted intermediary, control alternate access paths, and ensure externally supplied identity headers cannot masquerade as trusted ones.
The objective is an explicit trust model that remains enforceable across the paths through which a service can be called.
A Boundary Does Not Always Need Another Microservice
There is another distinction worth making.
A service boundary is a logical responsibility. It does not necessarily require an additional deployable component.
Depending upon the application, that responsibility could be implemented using a request filter, framework security configuration, controller validation, application service, or a dedicated entry service.
Creating another network hop merely to demonstrate that a boundary exists may introduce operational work without adding a useful capability.
I would introduce a separate component when it has a clear purpose—for example, adapting an external contract, coordinating several backend capabilities, or providing a distinct security boundary.
Otherwise, the existing service may be perfectly capable of enforcing its own contract.
Keep Business Decisions Close to Their Owners
A gateway can gradually become an attractive home for almost any logic that touches a request.
A small routing condition becomes a customer-specific exception. That exception becomes a workflow decision. Eventually, understanding an operation requires reading both application code and a substantial collection of gateway policies.
My preference is to keep shared access policies at the gateway and business decisions close to the services that own the relevant data and behavior.
This makes the division easier to explain and maintain:
The gateway governs how callers reach a capability. The service determines whether a requested action is valid for the resource and its current state.
Closing Thoughts
An API gateway can simplify how we expose and govern services. Its introduction should also prompt us to make the remaining responsibilities clearer.
For each check, ask what information it needs, who owns that information, and which access paths must enforce it.
Once those questions have clear answers, we can centralize shared policies without weakening the services behind them—and retain meaningful service boundaries without creating unnecessary layers.
After all, a well-designed architecture should make responsibility easier to locate.
