API Gateway Patterns

API gateways are not just traffic routers. In serverless systems they often define the real edge contract: who can call the API, how requests are shaped, how aggressively traffic is limited, which responses can be cached, and which invalid requests are rejected before a function ever runs. This is one of the most important design choices in HTTP-facing serverless systems because pushing the right concerns into the gateway keeps handlers smaller, faster, and easier to govern.

The gateway should not become a hidden application server. But it should own the cross-cutting edge responsibilities that do not need to be reimplemented in every handler.

    flowchart TD
	    A["Incoming request"] --> B["Authenticate caller"]
	    B --> C["Match route"]
	    C --> D["Validate request shape"]
	    D --> E["Apply throttling or rate limit"]
	    E --> F{"Cacheable?"}
	    F -->|Yes| G["Return cached response or forward"]
	    F -->|No| H["Forward to function"]

What to notice:

• several important decisions can happen before the function runs
• pushing these concerns to the edge reduces repeated boilerplate
• the gateway is a policy boundary as much as a routing layer

What Usually Belongs in the Gateway

Strong gateway responsibilities often include:

• authentication and token verification
• route matching and version routing
• coarse request validation
• throttling and rate limiting
• response shaping for standard error envelopes
• caching for safe and predictable read paths

These are strong gateway concerns because they are shared, cross-cutting, and often independent of core business rules.

What Usually Belongs in the Function

The function should still own:

• domain-specific validation
• business logic
• authoritative state changes
• workflow or downstream events tied to the business action

The gateway should protect and shape the edge. It should not become the place where business meaning hides.

Why This Split Matters

If a team ignores gateway capabilities, every function repeats the same auth checks, rate limit behavior, and request validation patterns. That increases:

• code duplication
• inconsistency
• security drift
• latency from unnecessary handler execution

If the team pushes too much into the gateway, it risks building opaque policy and transformation layers that are hard to review. The goal is balance, not maximal edge logic.

Example: Gateway Configuration

 1gateway:
 2  route: GET /profiles/{id}
 3  auth:
 4    type: bearer
 5  request_validation:
 6    path_params:
 7      - id: uuid
 8  rate_limit:
 9    burst: 100
10    requests_per_minute: 600
11  cache:
12    enabled: true
13    ttl_seconds: 30
14
15function:
16  handler: src/profiles.get

This is strong because:

• malformed requests are rejected early
• auth is enforced consistently
• safe read traffic can benefit from caching
• the function only sees requests that already passed coarse edge checks

Common Gateway Patterns

Authentication at the Edge

This is usually the first and most important gateway capability. A function should not be spending most of its time repeatedly parsing and verifying tokens if the gateway can handle that reliably and consistently.

Throttling and Rate Limiting

These are critical for protecting both the function platform and downstream dependencies. A rate limit is not only an abuse-control feature. It is also a dependency-protection feature.

Request Validation

The gateway can reject obviously malformed requests early, which saves cost and reduces noise in handlers. The function still handles domain-level validation, but basic structural validation usually belongs at the edge.

Response Caching

Caching is powerful for read-heavy safe endpoints, but it needs discipline. Teams should cache only responses whose semantics remain safe under the chosen TTL and invalidation strategy.

Common Mistakes

• putting every validation rule into the function even when the gateway can reject bad requests earlier
• putting business rules into opaque gateway mappings and losing clarity
• treating rate limits as an afterthought rather than part of dependency protection
• enabling caching without being explicit about freshness and invalidation behavior

Design Review Question

A team runs all authentication, schema validation, throttling, and error-envelope formatting inside every function because “we want logic in one place.” The gateway only forwards traffic. Is that a strong gateway design?

Usually no. The stronger answer is that the gateway is underused. Cross-cutting edge concerns often belong there precisely so they can be enforced consistently and keep handlers focused on business behavior. Centralizing everything inside the function may feel tidy, but it usually creates repetition and weakens the actual edge boundary.

Check Your Understanding