API Gateway Design
You'll learn to
- -Explain what responsibilities belong in an API gateway versus in individual backend services
- -Design protocol translation at the gateway so internal services can use gRPC while external clients use REST or GraphQL
This module shifts from designing individual protocols to designing systems that combine several - starting with the API gateway, the single entry point that sits between external clients and a system's internal services, handling everything that would otherwise need to be duplicated across every single service.
What Belongs at the Gateway
- -Authentication: verifying the caller's identity once, at the edge, rather than every internal service re-implementing token validation.
- -Rate limiting: enforcing limits centrally, since a per-service limit can't see a client's total request volume across every service it calls.
- -Request routing: directing a request to the correct backend service based on path, headers, or other routing rules.
- -Protocol translation: accepting one protocol at the edge (REST, GraphQL) and translating to whatever internal services actually speak (often gRPC, for the performance reasons covered in the gRPC modules).
- -Cross-cutting observability: logging, metrics, and tracing in one consistent place for every request, regardless of which backend service ultimately handles it.
What Does NOT Belong at the Gateway
Business logic - the actual rules specific to orders, payments, or inventory - belongs in the services that own those domains, not in the gateway. A gateway that accumulates business logic becomes a shared bottleneck every team's changes have to route through, exactly the coordination problem schema federation solved for GraphQL specifically; keeping the gateway focused on cross-cutting, protocol-level concerns keeps it from becoming that bottleneck for business logic changes.
Protocol Translation in Practice
GET /api/orders/501
Authorization: Bearer eyJhbGc...// The gateway authenticates the REST request, then calls the internal
// OrderService via gRPC on the client's behalf:
service OrderService {
rpc GetOrder (GetOrderRequest) returns (Order);
}
// gateway maps: GET /api/orders/{id} -> GetOrder(GetOrderRequest{id: id})
// and maps the protobuf Order response back to a JSON body for the clientThis lets internal services standardize on gRPC's performance and strong typing for service-to-service calls, while external clients still get the REST (or GraphQL) interface they actually need - the gateway is the single place that bridges the two worlds, so no internal service has to speak multiple protocols itself.
A gateway becomes a single point of failure for the entire system by design - it needs its own resilience story (redundancy, health checks, graceful degradation) proportional to how much traffic depends on it, since an outage here affects every client of every service behind it, not just one.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Design Gateway Architect in the API Design Lab's Full System Design act.