Gateway decisions

• 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.

1. Client Gateway: GET /orders. Match the request against configured routes.
2. Gateway Service A: Forward. The route selects the orders service.
3. Service A Gateway: 200. The backend returns its authorized result.
4. Gateway Client: 200. The edge returns the response to the client.

Rate limiting

A limiter rejects a request before it consumes backend work.

1. Client Gateway: Request 101. The caller exceeds this example’s 100-request budget.
2. Gateway Client: 429. The gateway returns configured retry guidance.

Token rejection

A failed credential check does not forward to a protected backend.

1. Client Gateway: Expired token. The gateway checks configured token requirements.
2. Gateway Client: 401. The request needs valid credentials.

Load balancing

Distribute requests among healthy equivalent replicas; these two services are replicas in this scenario.

1. Client Gateway: Request A. Select a healthy replica.
2. Gateway Service A: A. The first request goes to replica A.
3. Client Gateway: Request B. A separate request arrives.
4. 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.

1. Client Gateway: GET public guide. The gateway evaluates cache policy.
2. Gateway Cache / metrics: Lookup. A fresh eligible representation exists.
3. Cache / metrics Gateway: Cached body. The cache supplies the result.
4. Gateway Client: 200 cached. Return the eligible representation.

Circuit breaker

An open circuit avoids repeatedly calling a failing dependency.

1. Client Gateway: Request. The gateway checks dependency health state.
2. 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.

1. Client Gateway: TLS connection. The edge terminates the client-side TLS session.
2. Gateway Service A: New TLS hop. This design establishes a separate protected upstream connection.
3. Service A Gateway: Upstream response. The response returns over the upstream TLS connection.
4. Gateway Client: Protected response. The edge returns it over client-side TLS.

API version routing

Versioned routes select explicit contracts.

1. Client Gateway: GET /v2/orders. Match a configured API version.
2. Gateway Service B: v2 upstream. The newer contract goes to service B.
3. Service B Gateway: v2 response. The upstream supplies the versioned representation.
4. Gateway Client: v2 response. The edge returns the selected version.