API Gateway

API Gateway

An API gateway sits on the north-south edge of your system and standardizes the boring but critical work: authentication, rate limits, logging, request shaping, and upstream routing. It is valuable when many clients hit many services, but it becomes dangerous when teams start treating it like an orchestration engine instead of a thin policy layer.

Minimal Example

const policies = [
  {
    match: /^/v1/orders//,
    upstream: "orders",
    auth: "jwt",
    rateLimitRps: 100,
  },
  {
    match: /^/v1/payments//,
    upstream: "payments",
    auth: "mtls",
    rateLimitRps: 20,
  },
];

export function routeRequest(path) {
  return policies.find((policy) => policy.match.test(path));
}

What It Solves

• Centralizes cross-cutting concerns so every upstream service does not re-implement auth, quotas, and headers differently.
• Hides internal service topology from clients so backends can move, split, or version without breaking every consumer.
• Creates a consistent place to emit request IDs, latency metrics, and upstream failure details.

Failure Modes

1. Putting business workflows in the gateway until it becomes the most complex service in the estate.
2. Masking upstream timeouts and error classes so debugging stops at the edge.
3. Scaling the gateway as one giant choke point instead of separating control-plane policy from data-plane traffic.

Production Checklist

• Keep routing and policy declarative; move business branching into services.
• Propagate trace IDs, caller identity, and upstream timing on every hop.
• Define clear fail-open versus fail-closed behavior for auth, quotas, and dependency outages.

Closing

A good API gateway is narrow, boring, and observable. The moment it starts owning domain logic, it stops being an edge component and becomes a liability.

---