API Gateway Architecture

The Problem the Gateway Solves

In the microservices era, a single user action — say, loading a social media feed — might require data from six or more independent services: user profiles, posts, recommendations, notification counts, advertisement targeting, and analytics. Without coordination, the mobile app must make six separate HTTP calls to six different endpoints, each with its own domain, TLS certificate, and authentication mechanism.

This creates an immediate set of engineering problems. From a security perspective, each service must independently validate every token. From a network performance perspective, mobile clients on constrained connections pay the full TCP+TLS handshake cost per request. From a development perspective, any change to an internal service URL immediately breaks all clients. The API Gateway pattern solves all three simultaneously.

The role of the Gateway is to provide a single, consistent interface for clients while hiding the complexity of the backend services. It acts as a gatekeeper, ensuring only authorized requests reach the internal services.

Technical Multi-Tool: Gateway Functions

Rate Limiting Strategies: The Engineering Trade-offs

Rate limiting at the gateway is deceptively complex. The naive approach — a simple request counter — breaks in a distributed environment where the gateway itself runs across 50 nodes. The actual implementation must choose between several algorithms:

Modern Pattern: The BFF (Backend for Frontends)

One gateway doesn't always fit all. A mobile app might need a tiny, highly-compressed response with only essential fields, while a Desktop Dashboard needs a massive data set with full metadata for rich table displays. The bandwidth constraints and UX requirements are fundamentally different.

The BFF Pattern, coined by Sam Newman at ThoughtWorks, creates dedicated gateways for specific client types. This allows the front-end teams to 'own' their gateway and optimize the data aggregation specifically for their UI needs. Netflix pioneered this approach, building separate BFFs for their TV app, iOS app, Android app, and web application — each making optimized calls to the same underlying microservices but returning different response shapes.

Observability: The Gateway as a Telemetry Hub

Because all traffic flows through it, the API Gateway is the ideal point to emit structured telemetry. Modern gateways like Kong, Envoy, and AWS API Gateway can automatically publish per-route metrics: request counts, error rates (4xx vs 5xx), p50/p95/p99 latencies, and upstream service health. This becomes the foundation for SLO-based alerting — the gateway literally tells you when you are burning your error budget.

Conclusion

The API Gateway is the face of your infrastructure. Done right, it provides a seamless and secure experience for the developer and the user, acting as a transparent traffic controller that makes dozens of internal services appear as a single, coherent system. Done wrong, it becomes a brittle shadow of the monolith we tried to escape — a 'distributed monolith in reverse' where all the complexity has been pushed to a single chokepoint. The key discipline is to keep the gateway thin: route, authenticate, rate-limit, and observe. Leave the business logic to the services.