# API Gateway

> **Single entry point for API traffic: routing, authentication, rate limiting, and protocol translation.**

***

## 1. Concept Overview

An **API gateway** sits between clients and backend services. It handles cross-cutting concerns (auth, rate limiting, logging, routing) so individual services can stay focused on business logic.

**Why it exists**: Without a gateway, every service would implement auth, rate limits, and routing; clients would need to know many endpoints. The gateway centralizes these and provides a single API surface.

***

## 2. Core Principles

### Typical responsibilities

| Responsibility           | Description                                                    |
| ------------------------ | -------------------------------------------------------------- |
| **Routing**              | Path/host → backend service (e.g. `/users` → user service)     |
| **Authentication**       | Verify JWT, API key, or OAuth; reject unauthenticated requests |
| **Authorization**        | Check permissions (e.g. scope, role)                           |
| **Rate limiting**        | Limit requests per user/key/IP; return 429 when exceeded       |
| **Protocol translation** | REST (public) → gRPC (internal); or GraphQL → REST backends    |
| **Caching**              | Cache responses for read-heavy endpoints                       |
| **Circuit breaking**     | Fail fast when backend is down; avoid cascading failure        |
| **Logging / metrics**    | Centralized access logs, latency, error rate                   |

### Architecture

```
  Clients (Web / Mobile / Partners)
        │
        ▼
  ┌─────────────────┐
  │   API Gateway   │  Auth, rate limit, route, cache
  └────────┬────────┘
           │
     ┌─────┼─────┬─────────┐
     ▼     ▼     ▼         ▼
  User  Order  Payment  Notification
  Svc   Svc    Svc      Svc
```

***

## 3. Real-World Usage

* **Kong**: Open-source; plugins for auth, rate limit, logging; on-prem or managed.
* **AWS API Gateway**: Managed; Lambda integration; usage plans and keys.
* **Google Apigee**: Enterprise; monetization, analytics.
* **Nginx / Envoy**: Often used as gateway with custom config or Lua/WASM.

***

## 4. Trade-offs

| Aspect                     | Pros                                    | Cons                                              |
| -------------------------- | --------------------------------------- | ------------------------------------------------- |
| **Centralized**            | One place for auth, rate limit, routing | Gateway is critical path and potential bottleneck |
| **Protocol translation**   | Clients use REST; internals use gRPC    | Extra hop and complexity                          |
| **Managed vs self-hosted** | Managed: less ops                       | Cost; less control                                |

**When to use**: Multiple services exposed as one API; need central auth, rate limit, or versioning.\
**When not**: Single service; or when a simple reverse proxy is enough.

***

## 5. Failure Scenarios

| Scenario               | Mitigation                                                           |
| ---------------------- | -------------------------------------------------------------------- |
| Gateway down           | Multiple gateway instances behind LB; stateless                      |
| Backend down           | Circuit breaker; return 503; retry with backoff                      |
| Auth/rate-limit bypass | Validate at gateway only; don’t trust client to send correct headers |
| Latency spike          | Timeouts; circuit breaker; scale gateway horizontally                |

***

## 6. Performance Considerations

* **Latency**: Gateway adds one hop; minimize logic and use connection pooling to backends.
* **Throughput**: Scale gateway horizontally; avoid heavy logic in hot path.
* **Caching**: Reduces backend load and latency for cacheable GETs.

***

## 7. Implementation Patterns

* **Gateway per environment**: One gateway for public API; optional separate for internal.
* **Backend for Frontend (BFF)**: Different gateway or route per client type (e.g. mobile vs web) to tailor responses.
* **Gateway + service mesh**: Gateway at edge; mesh handles service-to-service (mTLS, retries, discovery).

***

## Quick Revision

* **Role**: Single entry; routing, auth, rate limit, protocol translation, caching, circuit breaking.
* **Vs reverse proxy**: Gateway adds auth, rate limit, and often API-specific logic; reverse proxy is more generic.
* **Failure**: Stateless; multiple instances; circuit breaker to backends.
* **Interview**: “We use an API gateway for authentication and rate limiting so backends don’t each implement it; we route by path to the right microservice and can translate REST to gRPC internally.”