API Gateway Selection Guide: Kong vs APISIX vs Tyk vs Envoy — A Decision Framework
An API gateway is no longer just a reverse proxy — it is the central management hub for authentication, rate limiting, routing, observability, and protocol translation. This article compares five mainstream solutions — Kong, Apache APISIX, Tyk, Envoy (Gloo), and AWS API Gateway — across architecture model, performance benchmarks, plugin ecosystem, and operational costs. A reusable decision framework for backend developers and architects building or refactoring an API gateway layer.
The Bottom Line: An API Gateway Is Not a Nginx Replacement — It Is an API Management Hub
Many teams start with Nginx as a reverse proxy. As microservices grow and auth/rate-limiting needs emerge, the Nginx config balloons — Lua scripts scattered everywhere, rate limit thresholds hardcoded, canary deploys requiring manual upstream edits.
This is where an API gateway steps in. It extracts cross-cutting concerns — auth, rate limiting, routing, observability — from business code and centralizes them at the gateway layer. But pick the wrong gateway, and the complexity it introduces can outweigh the problems it solves.
This article compares five mainstream solutions and provides a reusable selection framework.
1. Five Solutions at a Glance
| Solution | Open Source / Commercial | Base Language | Architecture | Per-Core QPS | Plugins | Learning Curve |
|---|---|---|---|---|---|---|
| Kong | Open + Commercial | OpenResty/Lua | Proxy + Control Plane | ~70K | 200+ | Medium |
| Apache APISIX | Open | OpenResty/Lua | Proxy + Control Plane | ~180K | 100+ | Medium |
| Tyk | Open + Commercial | Go | Standalone + Dashboard | ~30K | Plugin-based | Low |
| Envoy/Gloo | Open + Commercial | C++ | Proxy + xDS Control Plane | ~220K | Lua/WASM | High |
| AWS API Gateway | Managed | - | Fully managed | Elastic | 20+ built-in | Low |
1.1 Kong
Strengths: Oldest community (2015), richest ecosystem with 200+ plugins covering auth, rate limiting, logging, transformation. Enterprise edition includes Dev Portal and API lifecycle management.
Weaknesses: No dashboard in the open-source edition; medium performance; route/plugin changes require reload (db cache mode available since 0.14 but still constrained).
Best for: Teams needing rich plugins, familiar with OpenResty/Lua, or requiring commercial support.
1.2 Apache APISIX
Strengths: 2-3x Kong’s performance; hot-reload — route, upstream, and plugin changes without any restart; Apache Foundation backing; multi-language plugin support (Lua, Java, Go, Python, WASM); native Kubernetes Ingress Controller.
Weaknesses: Younger community; inconsistent documentation quality; advanced features require custom plugin development.
Best for: Teams needing high performance, dynamic configuration, and native K8s deployment.
1.3 Tyk
Strengths: Go-based monolithic architecture — single binary deployment; built-in dashboard and API management UI; native GraphQL aggregation layer.
Weaknesses: Lower performance than OpenResty-based solutions; smallest community; advanced features require enterprise edition.
Best for: Small to mid-size teams wanting out-of-the-box functionality without OpenResty complexity.
1.4 Envoy / Gloo
Strengths: Performance ceiling — C++ implementation, 220K+ QPS per core; Envoy powers Istio’s data plane, making it the Service Mesh standard; xDS protocol is the industry-standard control plane protocol; WASM plugin hot-reload.
Weaknesses: Steep learning curve — xDS configuration is complex, requiring understanding of Listener/Cluster/Endpoint/Route abstractions; Gloo (commercial) pricing is opaque.
Best for: High-traffic scenarios, Service Mesh infrastructure, WASM-based customization needs.
1.5 AWS API Gateway
Strengths: Zero operations, auto-scaling, pay-per-call pricing; deep integration with Lambda/Auth0/Cognito/CloudWatch; native API versioning and deployment pipelines.
Weaknesses: Vendor lock-in — cannot migrate; 29-second timeout limit (HTTP API/REST API); limited customization; costs spike at high traffic volumes.
Best for: AWS full-stack teams, Serverless architectures, rapid prototyping.
2. Selection Decision Framework
Dimension One: Architecture Model
Two architectural models for API gateways:
Centralized Gateway: All traffic passes through a single gateway — unified governance but creates a single point of failure and potential bottleneck. Kong, APISIX, and Tyk all use this model.
Sidecar/Mesh Gateway: The gateway runs as a sidecar injected into each Pod — traffic governance is distributed to application-side sidecars, eliminating the single point. Envoy is the standard data plane for Service Mesh.
Decision: <50 microservices, traditional deployment → centralized gateway (APISIX/Kong); 50+ microservices, K8s-native → sidecar model (Envoy/Istio).
Dimension Two: Performance Benchmarks
| Gateway | P50 Latency | P99 Latency | Per-Core QPS | Memory (10K routes) |
|---|---|---|---|---|
| APISIX | 1.2ms | 3.5ms | 180,000 | ~40MB |
| Kong | 2.8ms | 8.1ms | 70,000 | ~50MB |
| Tyk | 4.1ms | 12.3ms | 30,000 | ~30MB |
| Envoy | 0.9ms | 2.8ms | 220,000 | ~60MB |
(Data source: official benchmarks on comparable 4C8G hardware.)
Dimension Three: Plugin Ecosystem
An API gateway’s core value lies in its plugins. Common needs fall into these categories:
Essential plugins: Key Auth / JWT Auth, Rate Limiting, ACL, CORS, Prometheus metrics
Recommended plugins: Request Transformer, Response Transformer, IP Restriction, Proxy Cache, gRPC transcoding
Advanced plugins: Canary Release, ACME (auto certificates), Request batching/coalescing, GraphQL aggregation
Kong has the most plugins (200+), but APISIX covers 90% of common needs and supports multi-language development.
Dimension Four: Operational Cost
| Aspect | Kong | APISIX | Tyk | Envoy/Gloo |
|---|---|---|---|---|
| Deploy complexity | Medium (DB + control plane) | Medium (etcd/DB + control plane) | Low (single binary) | High (xDS + control plane) |
| Ops tools | Kong Manager (enterprise) | APISIX Dashboard (open) | Tyk Dashboard (open) | Gloo UI (enterprise) |
| Hot reload | Requires reload (db cache) | Native | Supported | Native via xDS |
| K8s integration | Kong Ingress Controller | APISIX Ingress Controller | Tyk Operator | Envoy Gateway / Istio |
3. Scenario Matching
Scenario A: Small to Mid-Size Team, Fast Launch
Recommendation: APISIX (open source) or Tyk (open source)
APISIX Dashboard provides a UI for visual route/upstream/plugin management without YAML. Tyk offers the simplest deployment — single binary startup, suitable for 5-10 API scenarios.
Scenario B: High Traffic / Financial Grade
Recommendation: Envoy + Istio (Service Mesh) or APISIX
Envoy is the performance ceiling; combined with Istio, it enables canary releases, traffic mirroring, and fault injection. If your team isn’t ready for Service Mesh operational complexity, APISIX offers the best performance-to-complexity ratio.
Scenario C: Cloud-Native (Acceptable Vendor Lock-In)
Recommendation: AWS API Gateway (AWS stack) or Kong Konnect (multi-cloud)
Fully managed options minimize operational overhead, ideal for startup validation phases. Plan for migration by abstracting a gateway adapter layer — avoid tight coupling between business code and vendor-specific APIs.
Scenario D: Protocol Translation (REST↔gRPC/WebSocket)
Recommendation: APISIX or Envoy
APISIX natively supports gRPC proxying and gRPC-Web transcoding (via grpc-gateway). Envoy’s gRPC-JSON transcoder auto-exposes gRPC services as RESTful APIs using Proto annotations.
4. Gateway Best Practices
4.1 Authenticate at the Gateway, Not in Business Code
The gateway validates tokens (signature, expiry, blacklist) and passes identity as headers. Business services trust the headers, never parse tokens directly. This means switching auth schemes requires only gateway changes — zero business code impact.
4.2 Layered Rate Limiting
Gateway level: Global (by IP / API Key) → 1000 req/min
Service level: Business (by user / resource) → 100 req/min
Critical endpoints: Fine-grained (by operation type) → 10 req/min4.3 Observability Must Be Plumbed In from Day One
- Confirm Prometheus metrics coverage before enabling any plugin chain
- Pass TraceId from gateway to backend via OpenTelemetry header propagation
- Structured gateway logs (JSON) with requestId / latency / upstream_status / plugin_chain
4.4 Canary Release Through Traffic Routing
Use weighted routing or header matching to direct a small traffic percentage to new versions:
# APISIX example: 5% traffic to v2
upstream:
nodes:
"service-v1:8080": 95
"service-v2:8080": 5An API gateway is infrastructure — chosen well, it is the governance hub; chosen poorly, it is another layer of complexity. There is no universally best gateway, only the one that best fits your team size, traffic scale, and operational capability.
Need API gateway selection consulting or architecture review? Contact us — describe your interface scale and deployment environment, free feasibility assessment and recommendations within 24 hours.
Related reading
- REST vs GraphQL vs gRPC — upstream protocol selection
- API Security in Practice — complementary gateway auth approaches
- OpenAPI Best Practices — API specification management
FAQ
What is the difference between an API gateway and a reverse proxy?
A reverse proxy (Nginx, HAProxy) primarily handles load balancing, SSL termination, and static file serving. An API gateway extends this with route rewriting, authentication, rate limiting, circuit breaking, protocol translation (REST↔gRPC), API version management, request/response transformation, and traffic mirroring. In short: a reverse proxy is a transport-layer tool; an API gateway is an application-layer management platform. If you just need to forward requests, Nginx works. If you need authentication, rate limiting, or multi-version management, you need a gateway.
Which is better for production — Kong or APISIX?
Both are battle-tested. Kong has the oldest community (2015) and the richest plugin ecosystem (200+), with direct reuse of the OpenResty ecosystem and AWS-managed Kong Konnect. APISIX is newer (2019) but has clear advantages in performance (180K QPS per core vs Kong's 70K) and hot-reloading (route/plugin changes without restart). APISIX also has Apache Foundation backing. Recommendation: use Kong if you have an existing OpenResty/Nginx team; use APISIX if you need maximum performance or dynamic configuration.
How should authentication be handled at the gateway layer?
The gateway is ideal for one-time authentication — verifying token validity (signature, expiry, blacklist) and checking IP whitelists. It should not replace fine-grained authorization in business services. Recommended approach: the gateway validates the JWT and passes user identity as request headers (X-User-Id, X-User-Roles); downstream services implement business-level RBAC/ABAC using these headers. This means switching auth schemes only requires gateway changes — zero modifications in business services.
Can an API gateway become a performance bottleneck?
Yes, if poorly chosen. Each gateway hop adds HTTP round-trip and serialization/deserialization overhead. Benchmark data: Kong adds ~2-5ms latency, APISIX ~1-3ms, Envoy ~1-2ms. In most business scenarios (50-500ms API response time), the 2-5ms overhead is negligible. However, in high-frequency trading or real-time audio/video scenarios, either choose a high-throughput gateway (Envoy) or let critical paths bypass the gateway entirely.
This article comes from AI Enable Harness front-line delivery practice. Need a similar system or optimization service?
Subscribe to Updates
Get notified when new articles are published. No spam, occasional updates only.
Subscribe →