Innomerc Choose your depth. Learn at your own pace.
Understand it
An API gateway is an entry point that receives API requests and routes them to services. It can apply shared checks, such as validating a token or limiting request rates. It gives clients a stable entrance while services sit behind it.
Imagine Cedar has profile and order services. A gateway can route /profile to one and /orders to another. That routing is useful, but the order service still needs to decide whether the user may read a particular order.
Under the hood
Gateways may terminate TLS, authenticate requests, transform messages, cache responses and enforce quotas. The exact feature set varies. Upstream services must distinguish trusted gateway identity from attacker-controlled headers and direct traffic.
A gateway cannot infer every object-level business rule from a route alone. A token can be valid while the requested object belongs to another tenant. Prevent untrusted direct access to upstream services and keep application authorization authoritative.
Practitioner perspective
Model gateway failure behavior and trust propagation. If the authentication provider is unavailable, silently forwarding an unauthenticated request is a fail-open risk. Route matching, path normalization and header rewriting should be consistent with upstream interpretation.
Monitor policy denials, rate limits, upstream latency and dependency failures separately. A gateway can become a bottleneck or single failure domain unless capacity and resilience are designed. Logs should correlate across boundaries without exposing bearer tokens.
Watch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Gateway decisions
Watch traffic branch according to routing and shared edge policy.
Route matching selects a configured upstream; object permissions still belong in the application.
How to use this example
Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.
What it means
Everyday example
State in this scenario
Inspect components & read every step
- Client
A program that asks another system for information or an action.
Example: A shopping app requests a list of products from a service.
- Gateway
A system between a client and services that routes requests and may apply checks.
Example: It may reject a request over a configured rate limit before it reaches a service.
- Service A
One backend service or instance selected by the gateway.
Example: It may handle one route or receive part of a balanced workload.
- Service B
Another backend service or instance available to the gateway.
Example: A different API version may be routed here.
- Cache / metrics
A simplified box representing saved responses or request measurements, depending on the scenario. These are different jobs.
Example: Caching reuses a response; metrics count requests or measure their duration.
Request routing
Route matching selects a configured upstream; object permissions still belong in the application.
- Client Gateway: GET /orders. Match the request against configured routes.
- Gateway Service A: Forward. The route selects the orders service.
- Service A Gateway: 200. The backend returns its authorized result.
- Gateway Client: 200. The edge returns the response to the client.
Rate limiting
A limiter rejects a request before it consumes backend work.
- Client Gateway: Request 101. The caller exceeds this example’s 100-request budget.
- Gateway Client: 429. The gateway returns configured retry guidance.
Token rejection
A failed credential check does not forward to a protected backend.
- Client Gateway: Expired token. The gateway checks configured token requirements.
- Gateway Client: 401. The request needs valid credentials.
Load balancing
Distribute requests among healthy equivalent replicas; these two services are replicas in this scenario.
- Client Gateway: Request A. Select a healthy replica.
- Gateway Service A: A. The first request goes to replica A.
- Client Gateway: Request B. A separate request arrives.
- Gateway Service B: B. The next request goes to replica B.
Response cache
Only responses safe for the applicable key and authorization policy should be reused.
- Client Gateway: GET public guide. The gateway evaluates cache policy.
- Gateway Cache / metrics: Lookup. A fresh eligible representation exists.
- Cache / metrics Gateway: Cached body. The cache supplies the result.
- Gateway Client: 200 cached. Return the eligible representation.
Circuit breaker
An open circuit avoids repeatedly calling a failing dependency.
- Client Gateway: Request. The gateway checks dependency health state.
- Gateway Client: 503 / fallback. The configured failure response returns immediately.
TLS termination
An encrypted upstream hop is a separate connection; internal plaintext is not automatically safe.
- Client Gateway: TLS connection. The edge terminates the client-side TLS session.
- Gateway Service A: New TLS hop. This design establishes a separate protected upstream connection.
- Service A Gateway: Upstream response. The response returns over the upstream TLS connection.
- Gateway Client: Protected response. The edge returns it over client-side TLS.
API version routing
Versioned routes select explicit contracts.
- Client Gateway: GET /v2/orders. Match a configured API version.
- Gateway Service B: v2 upstream. The newer contract goes to service B.
- Service B Gateway: v2 response. The upstream supplies the versioned representation.
- Gateway Client: v2 response. The edge returns the selected version.
Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.
Open the detailed lesson walkthrough
Explore the system
Client
Alex requests one of Alex’s orders.
Read every step without animation
Allowed order request
- Client. Alex requests one of Alex’s orders.
- Gateway. The gateway verifies the token and applies request limits.
- Route. The path is forwarded to the order service.
- Order service. The service verifies Alex’s ownership of the order.
- Response. The permitted order returns through the gateway.
Shared edge checks and application permissions work together.
Wrong owner
- Client. Alex requests Sam’s order using a valid token.
- Gateway. The API access token is valid for this gateway, so this routing check passes.
- Order service. The service checks the object against Alex’s identity.
- Denied. The order is not returned because ownership does not match.
Authentication at the gateway is not object authorization.
Explore deeper: additional experiment
Which component must decide?
Routing and shared checks run at the gateway; resource-specific policy runs where the application can evaluate it.
A local teaching model with fictional inputs. It does not test a live system.
Attack view
A request carrying a valid token reaches a protected order route. Only the order service has the business context needed to verify that the order belongs to the requester.
Defender view
- Block unintended direct access to upstream services.
- Validate identity propagation and retain application-level authorization.
- Set request size, timeout and rate policies with explicit failure behavior.
Common mistakes
- A gateway does not replace secure application code.
- A WAF rule and object authorization are different controls.
Check your understanding
Active recall: explain this idea in 30 seconds
An API gateway is an entry point that receives API requests and routes them to services. It can apply shared checks, such as validating a token or limiting request rates. It gives clients a stable entrance while services sit behind it.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Read the editorial policy.