advanced

API gateway at the network edge

Place cross-cutting API concerns at the edge carefully: routing, auth handoff, rate limits, transforms, observability, and blast-radius control.

An API gateway sits at the perimeter and centralizes cross-cutting concerns: routing to microservices, authentication handoff, rate limiting, request/response transforms, and observability. Unlike a plain reverse proxy, it understands API contracts and consumer identity.

					Mobile/Web → API Gateway → Auth service
                        → Orders service
                        → Catalog service

Keep domain authorization inside services — the gateway validates tokens and forwards trusted identity headers; it should not become the only place permission rules live.

On interviews: contrast gateway vs service mesh sidecar; explain blast-radius when gateway config is wrong; when BFF (backend-for-frontend) replaces a shared gateway.

Common pitfalls: god-gateway with business logic; double billing of latency; single gateway as SPOF without HA planning.

The trade-off is operational consistency at the edge versus service autonomy and deployment independence.

Checklist:

Gateway owns perimeter policy, not domain rules.
Propagate identity, trace IDs, and tenant context.
Version routes for backward-compatible migrations.
HA and config rollout strategy for the gateway tier.