Over 71% of all web traffic now flows through APIs. That’s a lot of requests hitting your backend services without a traffic cop.
So, what is an API gateway, and why does almost every production system with more than a handful of services use one? It’s the single entry point that sits between your clients and your backend, handling routing, authentication, rate limiting, and response aggregation in one place.
This article covers how API gateways work, how they compare to load balancers and reverse proxies, their role in microservices architecture, the major platforms available (AWS API Gateway, Kong, Apigee), security considerations, and when you actually don’t need one.
What is an API Gateway
An API gateway is a server that sits between client applications and backend services. It acts as a single entry point for all incoming API requests, routing each one to the correct service and returning the combined response.
Think of it as the front desk of a large building. Every visitor checks in at one place, gets directed to the right floor, and never has to wander the hallways looking for the right office.
Without a gateway, clients would need to know the exact location and protocol of every individual service. That gets messy fast, especially in distributed systems running dozens (or hundreds) of microservices.
The gateway handles authentication, rate limiting, request transformation, logging, and traffic management, all before the request ever touches your back-end development layer. It centralizes these cross-cutting concerns so individual services don’t have to duplicate that logic.
Imperva’s 2024 State of API Security report found that 71% of all web traffic consisted of API calls. That volume alone justifies having a dedicated layer to manage, secure, and monitor API traffic.
Common implementations include AWS API Gateway, Kong, Google Cloud Apigee, Azure API Management, and open-source options like Tyk and KrakenD. Each one approaches the problem slightly differently, but the core function remains the same: receive the request, decide where it goes, and control what happens along the way.
The API gateway pattern became standard alongside microservices architecture. As monolithic applications split into smaller, independently deployable services, something had to sit in front of them and keep things organized. The gateway fills that role.
How an API Gateway Works
A client sends a single HTTP request to the gateway endpoint. The gateway then figures out which backend service (or services) should handle it, applies security and policy checks, forwards the request, and assembles the response before sending it back.
That’s the short version. The full lifecycle looks more like this:
- The client hits one URL. No need to know where individual services live.
- The gateway authenticates the request (JWT validation, OAuth token check, API key verification).
- Rate limiting and throttling policies kick in to protect backend services from overload.
- The gateway routes the request to the right service based on path, headers, or query parameters.
- If the request needs data from multiple services, the gateway fans out to each one and aggregates the responses.
- The final response goes back to the client as a single payload.
Salt Security’s 2024 report revealed that 95% of organizations experienced security issues in production APIs. Centralizing auth and policy enforcement at the gateway level catches problems before they reach individual services.
Request Routing and Composition
Path-based routing is the most common approach. A request to /api/users goes to the user service, /api/orders goes to the order service. Simple and predictable.
Header-based routing adds another dimension. The gateway can inspect headers like X-API-Version or Accept-Language and route accordingly.
Fan-out requests are where things get interesting. A mobile app loading a dashboard might need user profile data, recent orders, and notification counts, all from different services. The gateway makes those three calls in parallel, combines the results, and sends back one response. This cuts down on round trips and keeps client-side code cleaner.
Response aggregation is one of the biggest practical benefits. It reduces the complexity your front-end development team has to manage when building client applications.
Authentication and Rate Limiting at the Gateway Level
Handling auth at the gateway means your individual services don’t each need their own authentication layer. One place validates tokens, checks permissions, and rejects bad requests.
Common auth patterns handled at the gateway:
- OAuth 2.0 token validation
- JWT signature verification
- API key authentication
- IP whitelisting and blacklisting
API rate limiting prevents any single client from overwhelming your services. You set thresholds (say, 1,000 requests per minute per API key), and the gateway enforces them. API throttling works similarly but gradually slows responses instead of cutting them off entirely.
Akamai’s 2024 study found that 84% of security professionals experienced an API security incident in the past year, up from 78% in 2023. Gateway-level enforcement is the first line of defense against that trend.
API Gateway vs. Load Balancer
This confusion comes up constantly, and I get why. Both sit between clients and servers. Both distribute traffic. But they solve different problems at different layers.
A load balancer distributes traffic across multiple instances of the same service. If you have five copies of your user service running, the load balancer spreads requests evenly across them.
An API gateway routes traffic across different services. It looks at the request and decides whether it should go to the user service, the order service, or the payment service.
| Feature | API Gateway | Load Balancer |
|---|---|---|
| Operates at | Application layer (L7) with deep request inspection | Transport (L4) or Application (L7) |
| Routes between | Different services | Instances of the same service |
| Auth/security | Yes (JWT, OAuth, API keys) | No |
| Request transformation | Yes | No |
| Protocol translation | Yes (REST to gRPC, etc.) | No |
Most production architectures use both. The API gateway sits at the edge and routes requests to the correct service. Behind each service, a load balancer distributes traffic across that service’s instances.
Netflix built exactly this kind of setup. Their Zuul gateway handled request routing, authentication, and filtering at the edge. Behind Zuul, Netflix Ribbon provided client-side load balancing across service instances registered with Eureka for service discovery.
If you’re only running a single monolithic application across multiple servers, a load balancer is probably all you need. Once you split into microservices, the gateway becomes necessary.
API Gateway vs. Reverse Proxy
A reverse proxy forwards client requests to backend servers. It handles basic routing, SSL termination, and caching. NGINX and HAProxy are the classic examples.
An API gateway does all of that, plus a lot more.
Where the overlap exists:
- Both sit between clients and servers
- Both can terminate SSL/TLS connections
- Both can route requests based on URL paths
- Both can cache responses
Where the gateway goes further:
- Token-based authentication and authorization
- Rate limiting and throttling per client or API key
- Request and response transformation (rewriting headers, modifying payloads)
- API analytics and monitoring
- API versioning management
- Protocol translation between REST, gRPC, and WebSocket
Here’s what makes this tricky. NGINX and Envoy Proxy can function as both, depending on configuration. Kong is literally built on top of NGINX with a Lua-based plugin layer that adds gateway capabilities. Apache APISIX does the same thing.
The distinction matters most when you’re choosing tools for a software development process that involves multiple teams consuming different APIs. A reverse proxy alone won’t give you the API integration controls, developer portal features, or per-client analytics that a full gateway provides.
API Gateway in Microservices Architecture
Gartner research shows that 74% of organizations currently use microservices architecture, with another 23% planning to adopt it. A 2024 Solo.io survey puts enterprise adoption even higher, at 85%.
That adoption rate explains why API gateways went from “nice to have” to “standard infrastructure” in under a decade.
Without a gateway, every client needs to know the network location and protocol of each microservice. Change one service’s address or port, and every client breaks. Add a new service, and every client needs updating.
The gateway decouples clients from internal service structure completely. Your mobile app hits one endpoint. Your web app hits the same endpoint. Neither knows (or cares) how many services exist behind it.
Cross-cutting concerns the gateway handles in one place:
- Centralized logging and monitoring
- Authentication and authorization
- Rate limiting per consumer
- Request/response transformation
- Circuit breaking and failover
Service discovery tools like Consul and Eureka integrate directly with most gateways. When a new service instance spins up, the gateway knows about it automatically. When an instance goes down, traffic gets rerouted without manual intervention.
The global API gateway market was valued at approximately $4.3 billion in 2024, growing at a compound annual rate around 20%, according to Global Growth Insights. That growth directly tracks with microservices adoption across enterprises.
The broader software development process has shifted to accommodate this pattern. Teams working with containerization in development typically deploy their services behind a gateway from day one, especially when using Kubernetes-based orchestration with Envoy or Istio service mesh.
Backend for Frontend Pattern
The BFF pattern takes the gateway concept one step further. Instead of one gateway for all clients, you build separate gateways tailored to each client type.
Mobile gateway: returns smaller JSON payloads, strips out unnecessary fields, optimizes for bandwidth.
Web gateway: returns richer responses with full data sets that the browser can render.
Third-party gateway: enforces stricter rate limits and exposes only the public-facing API surface.
This pattern is common at companies handling large-scale traffic. Each gateway is owned by the team that builds the corresponding client, which keeps things clean and independent.
The BFF approach also simplifies mobile application development. Mobile teams can shape the gateway’s response format to exactly what their app needs, instead of filtering through a generic response designed for every possible consumer.
Core Features of an API Gateway
Every gateway handles routing. That’s table stakes. The features below are what separate a basic reverse proxy from a production-grade API gateway.
Request and Response Transformation
Gateways can rewrite requests before they reach backend services. This includes modifying headers, changing HTTP methods, restructuring JSON payloads, or adding correlation IDs for tracing.
Response transformation works the same way in reverse. The gateway can strip internal fields, rename properties, or convert XML responses to JSON before the client sees them.
This is especially useful when backend services use different data formats or when you need to maintain backward compatibility for older API consumers.
Caching at the Gateway Layer
Gateway-level caching stores responses for frequently requested endpoints and serves them directly without hitting backend services at all.
Imperva found that a typical enterprise site handled an average of 1.5 billion API calls in 2023. Even caching a small percentage of those requests significantly reduces backend load and improves response times.
Most gateways support configurable TTL (time-to-live) values per route, cache invalidation rules, and conditional caching based on request headers.
Logging, Monitoring, and Analytics
Every API call passing through the gateway creates an opportunity to collect data. Request counts, response times, error rates, payload sizes, consumer identity. All of it.
Gateways integrate with tools like Prometheus, Datadog, and CloudWatch to feed this data into monitoring dashboards. Some (like Apigee and Kong) include built-in analytics dashboards.
This visibility matters more than most teams realize. Only 10% of organizations consider their API security programs advanced, according to Salt Security. You can’t protect what you can’t see, and the gateway is the single best place to observe all API traffic.
Circuit Breaking and Failover
When a backend service starts failing or responding slowly, a circuit breaker in the gateway stops sending traffic to it. This prevents cascading failures across your entire system.
Three states in a typical circuit breaker:
- Closed: traffic flows normally
- Open: requests are blocked; the gateway returns a fallback response
- Half-open: a small number of test requests check if the service recovered
Netflix pioneered this pattern with Hystrix, and it’s now a standard feature in most gateway implementations. Combined with high availability design, circuit breaking keeps your system responsive even when individual services go down.
API Gateway Tools and Platforms
The API management market is projected to reach $32.48 billion by 2032, according to Coherent Market Insights. The gateway segment alone holds a 37.2% share of that market. Picking the right tool matters because you’ll live with this decision for years.
Here’s how the major options break down.
| Platform | Type | Best For | Key Tradeoff |
|---|---|---|---|
| AWS API Gateway | Cloud-managed | AWS-native stacks | Vendor lock-in |
| Kong | Open-source / Enterprise | Multi-cloud, plugin-heavy setups | Operational complexity |
| Google Apigee | Cloud-managed | Enterprise API lifecycle + monetization | Cost at scale |
| Azure API Management | Cloud-managed | Microsoft ecosystem teams | Azure dependency |
| Tyk | Open-source / Cloud | GoLang-native, lightweight deployments | Smaller plugin ecosystem |
| KrakenD | Open-source | High-performance aggregation | No built-in admin UI |
Kong benchmarks above 50,000 transactions per second per node, according to Kong Inc. Apigee leads in built-in monetization and analytics dashboards. AWS API Gateway wins on zero-ops simplicity if you’re already deep in the AWS ecosystem.
Service mesh gateways like Envoy Proxy (used inside Istio) handle east-west traffic between services, while traditional API gateways manage north-south traffic from clients. Some teams run both.
Managed vs. Self-Hosted API Gateways
Managed gateways (AWS, Apigee, Azure) remove operational burden. You don’t provision servers, patch software, or manage uptime. The provider handles all of that. The tradeoff is less control and potential vendor lock-in.
Self-hosted gateways (Kong open-source, Tyk, Apache APISIX, KrakenD) give you full control over deployment, configuration, and data residency. You own the infrastructure. You also own the maintenance.
The decision usually comes down to your team’s capacity. If you have a strong DevOps culture and dedicated infrastructure engineers, self-hosted makes sense. If your team is small and wants to focus on building features, managed is the faster path.
A hybrid approach works too. Kong Konnect, for instance, manages the control plane in the cloud while you run data plane nodes in your own environment. That keeps sensitive API traffic inside your network while offloading management overhead.
When You Don’t Need an API Gateway
Not every project needs one. Adding a gateway to a simple architecture introduces complexity that might not pay off.
Skip the gateway when:
- You’re running a monolithic application with a single backend. A reverse proxy like NGINX does the job.
- Your project has fewer than 3-4 services and a single client type
- You’re building an internal-only API where auth and rate limiting aren’t needed
Every request through a gateway adds a network hop. That’s usually a few milliseconds, but it adds up under heavy load. For latency-sensitive applications with simple routing needs, that overhead might not be justified.
The bigger risk is treating the gateway as a monolithic orchestrator. When teams start packing business logic into the gateway (data transformations, complex workflows, conditional routing based on payload content), it becomes a bottleneck and a single point of failure.
Took me a while to fully appreciate this, but a gateway should stay thin. Route traffic, enforce policies, aggregate responses. That’s it. The moment it starts making business decisions, you’ve recreated the monolith you were trying to escape.
If you’re early in the software development process and still validating your product, a gateway is probably premature. Get the core codebase working first. Add the gateway when your service count and client complexity genuinely demand it.
API Gateway Security Considerations
FireTail’s 2024 report found that API data breaches increased 80% year over year, with over 1.6 billion records exposed. The gateway is the first place to stop that from happening.
Every API call enters through the gateway. That makes it the natural enforcement point for security policies across your entire software system.
TLS Termination and Mutual TLS
TLS termination at the gateway encrypts traffic between clients and the gateway, then passes unencrypted requests to backend services over your internal network. This offloads the CPU cost of encryption from individual services.
Mutual TLS (mTLS) goes further. Both client and server present certificates, verifying identity in both directions. Service mesh tools like Istio enforce mTLS between services automatically. The gateway handles the external-facing side.
Input Validation and Payload Inspection
Salt Security found that broken object-level authorization (BOLA) accounts for roughly 40% of all API attacks, according to OWASP data. Gateways can catch malformed requests, oversized payloads, and suspicious patterns before they reach your services.
Gateway-level validation typically includes:
- Schema validation against OpenAPI Specification definitions
- Payload size limits
- Header injection detection
- SQL injection and XSS filtering on query parameters
This is not a replacement for service-level validation. It’s a first filter. Defense in depth, not defense in one place.
DDoS and Abuse Protection
Akamai reported a 32% increase in attacks exploiting OWASP API Security Top 10 risks. Rate limiting and throttling at the gateway level are the most direct defenses against volumetric abuse.
Beyond basic rate limits, production gateways can flag anomalous traffic patterns, like a single API key suddenly making 10x its normal request volume, or requests coming from geographic regions that don’t match the client’s profile.
Cloudflare, Kong, and Apigee all offer built-in DDoS protection features. For self-hosted gateways, you’d typically pair them with a WAF (Web Application Firewall) or a cloud-based DDoS mitigation service.
The token-based authentication layer at the gateway also helps. If a request can’t present a valid JWT or API key, it gets rejected before consuming any backend resources. Simple, but effective.
How to Set Up an API Gateway
Setting up a gateway is less about the installation and more about the decisions you make around routing, security, and observability. The install itself takes minutes with most tools. Getting the configuration right takes longer.
Choosing Your Gateway
Start with your stack. Already on AWS with Lambda functions? AWS API Gateway is the path of least resistance. Running Kubernetes? Look at Kong, Envoy, or Traefik. Building on Spring Boot? Spring Cloud Gateway integrates cleanly.
| Your Stack | Best Fit Gateway | Why |
|---|---|---|
| AWS Lambda / ECS | AWS API Gateway | Native integration, serverless support |
| Kubernetes | Kong / Envoy / Traefik | K8s-native, ingress controller support |
| Spring Boot microservices | Spring Cloud Gateway | Same ecosystem, reactive support |
| Multi-cloud | Kong / Tyk | Cloud-agnostic deployment |
| Google Cloud | Apigee | GCP integration, analytics built-in |
If your team already follows a software development plan with defined infrastructure choices, the gateway should align with those decisions rather than force a new toolchain.
Defining Routes, Services, and Policies
Routes map incoming request paths to backend services. A route like /api/v1/users/ points to your user service, /api/v1/orders/ to orders.
Upstream services are the actual backend targets. Each route connects to one or more upstream endpoints, with health checks configured to remove unhealthy instances from rotation.
Policies sit on top of routes. Authentication requirements, rate limits, request size caps, CORS rules. These get applied per-route or globally depending on your needs.
Most gateways support declarative configuration through YAML or JSON files, which means you can version control your gateway config alongside your source control management setup.
Testing and Monitoring
Load test the gateway before going live. Tools like k6, Gatling, or Apache JMeter simulate real traffic patterns and expose bottlenecks before your users do.
Observability matters just as much. Connect your gateway to monitoring tools early in the setup process.
- Prometheus + Grafana: open-source metrics and dashboards
- Datadog: managed APM with API-specific views
- CloudWatch: native option for AWS API Gateway
Track request latency, error rates by route, and throttled request counts from day one. If something breaks at 2 AM, your dashboards should tell you where.
A solid build pipeline should include gateway configuration validation as part of continuous integration. Catch misconfigurations before they hit production, not after.
Finally, document everything. Your technical documentation should cover route definitions, auth requirements per endpoint, rate limit thresholds, and escalation procedures for gateway incidents. The team that inherits your setup will thank you.
FAQ on What Is API Gateway
What is an API gateway in simple terms?
An API gateway is a server that acts as a single entry point for all client requests. It routes each request to the correct backend service, handles authentication, and returns the combined response.
What is the difference between an API and an API gateway?
An API is an interface that lets applications communicate. An API gateway manages, secures, and routes traffic across multiple APIs. One is the door. The other decides who gets through it.
Do I need an API gateway for microservices?
If you’re running more than a few services, yes. The gateway decouples clients from your internal microservices architecture, centralizes auth, and prevents clients from needing to know every service address.
What is the difference between an API gateway and a load balancer?
A load balancer distributes traffic across instances of the same service. An API gateway routes requests across different services and adds authentication, rate limiting, and request transformation on top.
Is NGINX an API gateway?
NGINX works as a reverse proxy and can handle basic routing and SSL termination. But it lacks built-in auth, analytics, and API management features. Tools like Kong add those capabilities on top of NGINX.
What are the most popular API gateway platforms?
The leading options include AWS API Gateway, Kong, Google Cloud Apigee, Azure API Management, Tyk, and KrakenD. Cloud-managed and open-source options both exist depending on your team’s needs.
How does an API gateway handle security?
It validates tokens (JWT, OAuth), enforces rate limiting, terminates TLS connections, inspects payloads, and blocks malicious requests. All of this happens before traffic reaches your backend services.
Can an API gateway become a single point of failure?
Yes, if deployed as a single instance. Production setups run multiple gateway nodes behind a load balancer with health checks and automatic failover. Managed services like AWS handle this for you.
What is the Backend for Frontend pattern in API gateways?
BFF means building separate gateways for each client type. A mobile app gets a lightweight gateway. A web app gets a richer one. Each returns only the data its client actually needs.
When should I not use an API gateway?
Skip it for monolithic applications, small internal APIs, or early-stage projects with minimal services. The added network hop and operational overhead aren’t worth it until your architecture genuinely demands it.
Conclusion
Understanding what is API gateway comes down to one thing: controlling how traffic moves between clients and services. Whether you pick AWS API Gateway, Kong, or Apigee, the gateway pattern solves routing, security, and observability in a single layer.
The real value shows up at scale. When your system grows past a few services and multiple client types start consuming your APIs, centralized request routing, JWT validation, and rate limiting stop being optional.
But don’t over-engineer early. Match the tool to your actual complexity. A monolith doesn’t need a gateway. A distributed system with dozens of services across containerized environments absolutely does.
Start with clear route definitions, solid auth policies, and proper monitoring. Build from there as your software scalability requirements grow.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
