API Gateway: One Front Door for Your APIs

Q: Do I need an API gateway for a monolith?

You need some front door — TLS, rate limiting, security headers — which Nginx or your cloud load balancer covers. A dedicated gateway earns its place when you have multiple services, public API keys/quotas to manage, or partner-facing APIs needing a developer portal.

Q: How do gateways handle versioning?

Routing rules map /v1/ and /v2/ (or header-based versions) to different backends, which enables gradual migration and canary releases without client awareness — see API Versioning.

API Gateway

An API gateway is a single entry point that sits in front of your backend services. Clients call the gateway; the gateway authenticates, rate-limits, and routes each request to the right service — so twelve microservices don't each reimplement auth, throttling, CORS, and logging twelve slightly different ways.

The pattern is near-universal in microservice architectures and increasingly common in front of monoliths too, because the alternative — every service exposed directly, every cross-cutting concern duplicated — decays fast. If you've called a public API through api.company.com, you almost certainly talked to a gateway.

TL;DR

A gateway centralizes the cross-cutting concerns of API traffic: authentication, rate limiting, routing, TLS, CORS, request/response transformation, and metrics.
Services behind it stay simpler and uniform — they trust the gateway's identity header instead of re-validating credentials.
Main flavors: cloud-managed (AWS/Azure/GCP API Gateway), self-hosted (Kong, KrakenD, Tyk, APISIX), or build-your-own on Nginx/Envoy.
The BFF pattern (Backend-for-Frontend) gives each client type its own tailored gateway instead of one generic one.
Gateways handle north–south traffic (clients → services); a service mesh handles east–west (service ↔ service). Complements, not competitors.
Biggest failure mode: letting business logic creep into the gateway until it becomes a fragile, shared monolith at the edge.

What a Gateway Does

A typical configuration (Kong, declarative):

The orders service itself now contains zero auth or throttling code.

Core Patterns

Gateway Authentication, Trusted Headers

The gateway validates the credential and passes verified identity downstream:

⚠️ This only works if services are unreachable except through the gateway (private network / network policy). If a client can hit a service directly and forge X-User-Id, the model collapses. Lock the network, or have services verify a gateway-signed token (or use a service mesh with mTLS).

Backend-for-Frontend (BFF)

One generic gateway serves every client badly: mobile wants small payloads, web wants rich ones, partners want stability. The BFF pattern gives each client class its own gateway that aggregates and shapes responses for that client:

Each BFF is owned by the frontend team it serves — which is the point.

Aggregation and Composition

A gateway (or BFF) can fan out one client call to several services and merge the results — saving mobile clients three round trips. Use sparingly: heavy composition logic is application code wearing a gateway costume; consider GraphQL federation when clients need flexible composition at scale.

Choosing a Gateway

Rule of thumb: on a cloud with serverless backends, use that cloud's gateway; on Kubernetes, use an ingress-capable gateway (Kong, APISIX, Envoy-based); for a handful of services, Nginx may be all the gateway you need.

Common Mistakes

Business Logic in the Gateway

Transformation plugins grow into order-validation rules, then pricing logic. Now every deploy risks all APIs at once, and the logic lives in a DSL nobody tests. Gateways handle traffic concerns; domain logic belongs in services.

The Gateway as Single Point of Failure

Everything flows through it — so it must be redundant (multiple instances behind a load balancer or anycast), monitored, and capacity-planned. A gateway outage is a total outage.

Forgetting It Adds a Hop

Every request pays the gateway's latency (usually single-digit ms, but budget it) and its timeout/retry configuration interacts with downstream ones. Misaligned timeouts — gateway retries a request the service is still processing — create duplicate writes; keep retries idempotent-only.

Bypassable Backends

If orders-service:3000 is reachable from outside, every gateway policy is optional. Enforce network-level isolation from day one.

One Gateway Config Owned by Everyone

When forty teams edit one shared gateway config, it becomes the org's most feared file. Prefer per-team route ownership (Kubernetes ingress CRDs, declarative config per service, or BFFs).

FAQ

Do I need an API gateway for a monolith?

You need some front door — TLS, rate limiting, security headers — which Nginx or your cloud load balancer covers. A dedicated gateway earns its place when you have multiple services, public API keys/quotas to manage, or partner-facing APIs needing a developer portal.

API gateway vs load balancer?

A load balancer distributes traffic to identical instances (L4/L7, mostly content-agnostic). A gateway is API-aware: it authenticates, applies per-consumer policy, and routes by path/version to different services. Gateways usually sit behind or replace the L7 balancer; see Load Balancing.

API gateway vs service mesh?

Gateway = north–south (external clients into the system). Service mesh = east–west (service-to-service mTLS, retries, traffic shifting inside the cluster). Large systems run both; the gateway often ends up as the mesh's ingress.

How do gateways handle versioning?

Routing rules map /v1/* and /v2/* (or header-based versions) to different backends, which enables gradual migration and canary releases without client awareness — see API Versioning.

What about GraphQL?

A GraphQL server is a form of gateway (one endpoint, composition, per-field auth). Many stacks put a conventional gateway in front of it anyway for TLS, rate limiting, and key management — the concerns are complementary.