API Gateway & Service Boundaries
The problem
When a system is split into many services, clients shouldn't need to know about every single one, their addresses, or their individual failure modes — an API gateway gives clients one stable entry point, hiding the internal service topology and handling cross-cutting concerns (auth, rate limiting) in one place instead of duplicating them in every service.
Why now
Monolith vs. microservices already established that splitting a system creates many independently addressable services; middleware and request pipelines already established that shared concerns (auth, logging) benefit from being handled once rather than duplicated. An API gateway is that middleware pattern, applied at the boundary of an entire distributed system rather than inside one server.
Mental model
An API gateway is a single front door: clients only ever talk to it, and it routes each request to the correct internal service, hiding exactly how many services exist or how they're organized behind that door. It's also the natural place to put anything every request needs regardless of which service handles it — authentication, rate limiting, logging — the same middleware-chain idea already covered, just positioned at the system's edge instead of inside one server.
Requires
- Monolith vs. MicroservicesSoftware Architecture
An API gateway exists specifically to manage the complexity of many independently deployable services; you need that many-services reality already established before a single unifying entry point in front of them has a problem to solve.
- REST API DesignBackend Engineering
A gateway routes and often reshapes REST API calls to internal services; you need the resource/method-oriented API design already covered as the thing the gateway is presenting a unified, client-facing version of.
Used in
- API gateways (Kong, AWS API Gateway, Nginx) sitting in front of microservices architectures
- Centralizing authentication so individual services don't each reimplement it
- Backend-for-frontend (BFF) patterns, a gateway tailored to one specific client's needs
- Hiding internal service refactors from external clients entirely
Projects
- Set up a simple API gateway in front of two backend services, routing requests to the correct one based on path, with authentication handled once at the gateway
- Refactor an internal service split (e.g. splitting one service into two) and confirm external clients see zero difference because the gateway's public interface didn't change
Examples
- A client calling api.example.com/orders never needs to know that request is actually routed internally to an orders-service running on a completely different set of machines
- Centralizing authentication at the gateway means adding a new internal service doesn't require reimplementing auth — it inherits the gateway's already-verified identity
Resources
Mastery checklist
- I can explain what problem an API gateway solves in a multi-service architecture
- I can set up basic path-based routing through a gateway to multiple backend services
- I can explain why centralizing auth at the gateway avoids duplicating it in every service
- I can explain how a gateway lets internal service boundaries change without breaking external clients