ADevGuide 
When a mobile app needs orders, profile, and recommendations, exposing three internal services directly makes authentication, versioning, and client logic leak everywhere. An API gateway gives clients one controlled entry point - but it can also become a latency bottleneck or a misplaced home for business rules.
This guide explains what belongs at the gateway, what does not, and how to state the trade-offs in a backend interview. It builds on stateless vs stateful architecture and the Backend Developer Interview Guide. For a direct comparison with load balancers and reverse proxies, see API Gateway vs Load Balancer vs Reverse Proxy.
Table of Contents
Open Table of Contents
What an API Gateway Is
An API gateway is an API-aware reverse proxy that presents a single public entry point for one or more backend services. It matches a request by host, path, method, or headers, enforces cross-cutting policy, and forwards it to an upstream service. The value is consistency: clients do not have to discover every internal service or repeat edge security and observability work.
It is not automatically required for every application. A small monolith with a few internal endpoints may add operational complexity without gaining much. The pattern becomes useful when many clients or services need a stable, governed boundary.
Request Flow
flowchart TD
A[Client] --> B[API gateway]
B --> C{Authenticate}
C -->|Invalid| D[401 response]
C -->|Valid| E{Rate limit}
E -->|Exceeded| F[429 response]
E -->|Allowed| G{Route match}
G --> H[Orders service]
G --> I[Profile service]
H --> J[Gateway response]
I --> J
J --> K{Client retry?}
K -->|Safe or idempotent request| B
K -->|No retry| A
classDef flow fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#000000;
class A,B,C,D,E,F,G,H,I,J,K flow;The gateway rejects invalid or over-limit traffic before it consumes downstream capacity. It should attach request IDs, traces, and carefully bounded timeouts so operators can find the service responsible for a failure.
Responsibilities That Belong at the Edge
Routing, TLS termination, authentication token verification, coarse authorization, rate limiting, request-size limits, CORS policy, and telemetry are strong gateway responsibilities. They apply consistently across many APIs and are easier to operate once than reimplement in every service.
Response aggregation can help a mobile client avoid several round trips. Treat it carefully: a gateway that starts deciding order eligibility, inventory reservation, or payment rules has become a second business service with unclear ownership. Prefer a backend-for-frontend or dedicated composition service when aggregation contains domain behavior.
What Should Stay in Services
The service that owns a resource remains the authority for business authorization and validation. A gateway can verify a caller’s identity, but it cannot safely decide whether that caller may refund a particular order without the order domain’s context. Domain transactions, persistence, and sensitive business policy must stay close to the owning service.
Reliability and Scaling
Deploy gateways as multiple stateless instances across failure zones and place health checks, connection limits, and safe timeouts in front of upstreams. Avoid blind retries for non-idempotent requests: retrying a payment create can duplicate side effects unless the downstream contract supports an idempotency key. A gateway should fail fast and return a useful error when an upstream is unavailable rather than holding every client connection open.
Gateway vs Load Balancer
A load balancer distributes traffic across interchangeable copies of one target. An API gateway chooses between different API services and applies API-level policy. They often work together: the gateway routes /orders to the orders service, then a service-level load balancer chooses one healthy orders instance. For the broader platform context, browse the Backend category. The next comparison article also separates these roles from a general reverse proxy.
Interview Questions
1. Is an API gateway a single point of failure?
It can be if deployed as one instance, so production gateways are replicated across zones and monitored like any critical edge tier. The logical entry point is single; the infrastructure should not be. Explain the failure mode and the mitigation rather than claiming the pattern has no risk.
2. Should services call each other through the gateway?
Usually no. Gateways are optimized for north-south client traffic, while internal east-west traffic needs service discovery, identity, and resilience appropriate to service-to-service calls. Sending internal calls through the public gateway adds hops and can apply the wrong client policies.
3. Where should authorization happen?
The gateway can perform coarse checks such as token validity or scopes, but the owning service must enforce domain authorization. That gives defense in depth and keeps resource-specific rules with the data and business logic they depend on.
4. How do you prevent gateway latency from hurting users?
Keep policy work lightweight, reuse connections, cache safe configuration and keys, set strict upstream timeouts, and avoid unnecessary aggregation. Measure gateway latency separately from service latency so a slow edge configuration is visible during an incident.
5. When would you avoid an API gateway?
For a small internal service or simple monolith, direct routing may be easier to operate. Add a gateway when it solves a concrete boundary problem - many clients, many services, shared policy, or controlled public exposure - not simply because the architecture has a fashionable name.
Conclusion
- An API gateway is a public API boundary, not a replacement for domain services.
- Centralize repeatable edge policy such as routing, authentication, rate limits, and telemetry.
- Keep business decisions and resource authorization in the owning service.
- Replicate the gateway, bound retries and timeouts, and measure it as a critical dependency.
The next topic in this series covers API rate limiting - the policy that protects shared capacity at the gateway and service layers. For the lower-level distribution role, review load balancing.
References
- What is Amazon API Gateway? - AWS https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
- What is an API Gateway? - IBM https://www.ibm.com/think/topics/api-gateway
YouTube Videos
- “API Gateway: An overview, explained with diagrams and flow” https://www.youtube.com/watch?v=5r8PWCK8qhA