When you split a monolith into microservices, clients suddenly face a problem: which of the 47 services do they call, and in what order? The API Gateway pattern puts a single entry point in front of your service mesh. Clients talk to the gateway; the gateway handles routing, authentication, rate limiting, request aggregation, and protocol translation.

Think of it as a hotel concierge. Guests don't wander into the kitchen, the laundry, and the maintenance office separately — they call the front desk, which routes their request to the right department.

What a gateway typically does:

• Routing: /api/orders/* → order-service, /api/users/* → user-service
• Auth: Validate JWT once at the edge instead of in every service
• Rate limiting: 1000 req/min per API key, enforced before traffic hits backends
• Aggregation: One client request fans out to 3 services, results merged into one response
• Protocol translation: Public REST/JSON in, internal gRPC out
• Observability: Every request logged and traced at a single chokepoint

Real-world example: A mobile app's "order details" screen needs the order, the user's shipping address, the product images, and tracking status. Without a gateway, the app makes four round trips over flaky mobile networks — each with its own auth, retries, and TLS handshake. With a gateway, the app makes one call to GET /orders/123/detail. The gateway parallel-fetches from order-service, user-service, catalog-service, and shipping-service, then returns a merged payload. Latency drops from 4×150ms serialized to ~180ms parallel.

Rule of thumb: If a typical client-facing page requires more than 2 backend calls, you probably need a gateway (or a BFF, which is a specialized gateway). If clients are issuing N+1 calls because "the API is too granular," that's a gateway-shaped problem.

Watch out for:

• The god-gateway anti-pattern. Don't put business logic in the gateway — it becomes a distributed monolith with all the coupling and none of the benefits. Routing, auth, transformation: yes. Tax calculations: no.
• Single point of failure. The gateway must be horizontally scalable and stateless. If it dies, everything dies. Run it across availability zones with health checks.
• Latency tax. Every request now has an extra hop. Budget 5–20ms and make sure the gateway is in the same region/VPC as your services.
• Deployment coupling. If every service change requires a gateway config update, you've recreated the coordination problem microservices were supposed to solve. Use declarative, per-service routing configs that teams own themselves.

Common implementations: Kong, AWS API Gateway, Envoy, Traefik, NGINX. For internal-only meshes, Istio or Linkerd often replace the explicit gateway with a sidecar-driven approach.