API Gateway: The Front Door for Your Microservices
An API Gateway is the single front door for all your backend services. It handles tasks like authentication and rate limiting before routing requests to the correct microservice. The footgun is treating it as a simple proxy; it can become a bottleneck.
WHY IT EXISTS: As applications grow, they are often broken down into smaller, independent microservices. Without a gateway, client applications would need to know the address of every single service, handle authentication for each one, and manage failures. This creates immense complexity and tight coupling between the client and the backend architecture.
THE MENTAL MODEL: Think of an API Gateway as the front desk or security checkpoint for a large office building. It's the single, public-facing address. All visitors (requests) must check in there first. The front desk verifies their identity (authentication), ensures they're allowed in (authorization), logs their visit (analytics), and then directs them to the correct office (microservice).
HOW IT WORKS: A client sends a request to the gateway's public endpoint. The gateway intercepts this request and performs several tasks. First, it authenticates the client, often by checking an API key or token. Second, it can enforce usage policies, like rate limiting, to prevent abuse. Third, it determines which backend service should handle the request based on the path or other details. Finally, it forwards the request to that service, waits for the response, and then returns it to the client, potentially transforming it along the way.
WHEN TO USE IT: An API Gateway is most valuable in a microservices architecture to provide a clean, unified interface for external clients. Use it to centralize cross-cutting concerns like authentication, logging, and rate limiting instead of implementing them in every service. It's also key for publishing a public API and managing its subscribers.
WHEN NOT TO USE IT: For a simple monolithic application, a gateway is often overkill; a standard load balancer may be sufficient. The primary danger is putting too much business logic into the gateway itself. If it starts orchestrating complex calls or transforming data heavily, it can become a new, centralized monolith and a performance bottleneck.
ONE CANONICAL EXAMPLE: A mobile app needs to show a user's profile and their recent orders. Instead of calling the User Service and Order Service directly, it makes one call to api.example.com/dashboard. The API Gateway authenticates the request, calls the two internal services, combines their responses into a single payload, and returns it to the mobile app.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.